Code that isn’t at all poetry, but that is structure & patterns

Happy Poetry Month! Rather than poeting, for the past few days I’ve been twiddling with code. It is much the same state of mind as translating, or basic composition, but for me at least, not quite poetry. It does require moving a bunch of words around, arranging them, and imagining their interpretation, organizing words in order to have an effect. For poetry or composition, an effect on a listener/reader, so you are imagining a logical and emotional state and the interpretation and effect of a person. For code obviously you are writing so that a machine will follow your orders perfectly; but less obviously you are writing for yourself in the future and for other future, human readers of your procedural pattern of thought. You are writing for your future (self or other) human, so they can modify and extend that code and put it to other uses. In other words, it has a bit in common with an oral or folk tradition. Repetition and patterns are good in poetry if you want to create structure for extension and improvisation.

So, just now I was doing some of my baby-Perl for some contract work. And the deal is, there are a bunch of users, and their accounts go through various bureaucratic steps, and through various work people and departments, some steps requiring others to happen first, for the account to become fully active. This is a fairly common situation for any institution. So, I had a Perl script that would take some command line options and then would do various things with the user and account data. As more people started realizing I could manipulate account stuff, and could generate reports, etc, they started asking me for new tasks. So, the hacky little script grew very quickly to a giant horrible tangly mess full of regular expressions that I did not understand anymore, 30 minutes after I wrote and tested them. A reg exp is a thing of beauty but it is not a joy forever. Instead, it makes my head hurt.

So I started about 4 times over this last month to rewrite that mess to make it easily understandable and extensible. I scribbled and thought on post-it notes so I could try to break down what needed to happen into chunks that I could move around & visualize, easier than in a 200 line text file.

It went kind of like this: use GetOpt::Long to tell from the command line what kind of report or change is required. Log in to several systems. Iterate over a range of account IDs in a big loop. Then do some http page getting and parsing. Then a lot of if else statements to see what command line option is turned on. Mixed in with some more tests and if elsing. Then again depending on command line option, do some other junk, write to some other web pages and outfiles. At the end of all that looping, write some more outfiles.

Ugh! You can see that any new capability meant that I had to do more page parsing and more reg exping, as well as thinking through all the logic of the whole if-else mess.

Today I suddenly realized several things. Speed doesn’t matter for this. I can set it going and let it chug away.

So, number one, for each user ID, just read in all the possible pages that have info on that account. It is only 5 web pages on 3 different systems. Read them in and parse out all their fields.

Number two, think of each account as having a state. There are 8 different bits of information that change account state, out of the 50+ possible bits of info. So, after parsing all the pages, look at the 8 pieces of information I care about, to determine the account’s state.

For things I then want to do, they fall into two categories. Reporting and state change. Reporting is easy. For changing account state, I can define for each case of one state to another; what actions it takes to change the account state. There are objects, and states, and transactions.

I have never really understood object-orientedness no matter how many times I think about it, and use and write code that is in theory, sort of object-oriented. It’s not like I get it now, but I get it more than I did.

Suddenly everything clicked into place and I understood how to write the code in a way that would be useful and elegant. I understood the root of the problem. It all fell together in a system. It looked like a pattern, like information that was beautiful. I know, it is a bunch of account data in a bureaucratic procedure. After years of being “programmer analyst” doing back end tools for university departments, I had to find beauty where I could. The “click” feeling means I look back on my month of sporadic attempts to write this program, and it looks like I was brain-deadishly trying to make something out of legos by gluing their corners together, when all the while I could have been snapping them together how they are supposed to go. But, before, I could not see the intersections.

So, just now I had the exhilarating (yet slightly shame-faced) feeling that I had just reinvented the wheel, or some basic principle of computer science that if I had any sense, I would have known from taking some classes. On the other hand, taking computer science classes doesn’t guarantee you know what you are doing or can build something that other people find useful & usable.

Related posts:
This entry was posted in Composite: Tech & Poetics and tagged , , , , . Bookmark the permalink.

2 Responses to Code that isn’t at all poetry, but that is structure & patterns

  1. gs says:

    Reading this post was like slipping my hand into a custom-made glove. I have experienced the same aargh-to-oh! journey many times.

    =It’s not like I get it now, but I get it more than I did.=

    I’ve done a number of OO projects now, and yet it seems that no matter how many I do, the next one is a struggle all over again. You are right: It’s not like I get it, I just get it more than I did, each time.

    The biggest obstacle for me is trying to figure out just what are the elemental objects, and what’s inside them, and what’s not. When you get the objects wrong, then coding becomes an ordeal of facing one problem after another.

    =Suddenly everything clicked into place and I understood how to write the code in a way that would be useful and elegant.=

    An awesome feealing, isn’t it? :) That’s what happens when you get the objects right. I know it seems silly — comparing such a small thing to such a big thing — but I’ve often wondered if that wasn’t the feeling that Einstein had, as he struggled with the seemingly intractable fact that the speed of light is constant, and then suddenly realized it all made sense if only time, mass, and distance were inconstant.

    =I understood the root of the problem.=

    In my (very) humble opinion, the most important factor in the success of an OO approach is to understand, as fully as possible and before trying to define any objects, the data, processes, and underlying nature of the situation being modeled. You had a great start with this project, because you had already written the application once, so you had already mastered the situation.

    Sorry to go on, but I can so relate. I hope you get to repeat the experience!

  2. craig says:

    That is why I love to program. Because of the feeling I get when everything just clicks. I know your a little different to me and you get satisfaction for different reasons because of your different interests.

    I in the past always wrote stuff and as soon as it became bigger it became harder to modify and extend on but now I have learnt to make my code oop and now all of my work can be easily read and extended on even if there is no need it just makes everything cleaner.

    I can sympathise with you I don’t completely understand oo but now I now it so much better then I did and I’m glad I made the effort.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>