Crap Code

I wrote a lot of crap code the summer of 1977. It was COBOL and not of the structured variety. Oh, it had a structure and I developed and adhered loosely to many standards I dreamed up, but I knew nothing of structured programming at the time. My boss and mentor hired me based on a referral from my undergraduate college when he was looking for a student for the summer. He saved me from starting either of the two jobs for which I had been hired that summer: nurse’s aid in a nursing home, which is what I had done from ages 17 – 19, and waitressing, a job for which no one who knew me thought me to be a good candidate. Those half-credit courses in COBOL, BASIC, and Fortran during my junior year of college paid off.

That summer I wrote Accounts Payable, Accounts Receivable, General Ledger, Payroll, and Depreciation systems for a storage company, from scratch. I had never taken an accounting course nor worked in that area, so I learned a lot. I learned about debits and credits and what a 10-key was. I was fast. I could write and maintain spaghetti code and manage volumes of important and sensitive data as if I had no clue to the relevance of any of it. There is something to be said for hiring students.

After I learned about structured programming, I was embarrassed by the code I had written. Some years later when I taught COBOL and suggested a student for my old employer to hire for the summer, I let that student know it was important to make sure all of my code was gone or rewritten. She should do as I said and not as I did in my past.

So now that I am back at it again, after a couple of decades away from heads-down coding, my code is more structured, more OO, more easily maintained than my 70’s code…in theory. I’m adding in after posting this that I should be clear that in the 80’s my code was pristine, lovely, elegant, and in the 90’s my OO code employed various elegant design patterns, so spaghetti code is not the only thing I have written.

We started this project as one of the first teams to attempt to use the Model-View-Controller approach with the Zen platform on Cache’ and a MultiValue database implementation. We were new to almost everything about it. Both the MV and AJAX implementations were relatively recent for InterSystems too and the combination of these was not yet out in general release, so there were glitches here and there.

Others on our team had programmed a lot of MV BASIC over the years, while I had not. Most of the production code I have written was COBOL with a good percentage of that being CICS, so I had to learn JavaScript and MV BASIC better, having previously had a bigger-than-a-breadbox taste of each.

With the Zen framework, we are writing XML specifications, OO declarations, SQL against MV structures, MVBASIC and JavaScript methods, html, and CSS. In some cases, every one of these languages is in a single Zen page class. While learning all of these pieces and how they interact, something we are still doing, we often employed a strategy of stopping once something worked. So, if we took four roundtrips when one ought to work, but we can figure out how to make it work with this platform with the four roundtrips to the server, then we get to the point where it works and we move on to the next thing.

I have a bunch of little to mid-sized changes to make to what we have done to date to enhance the user experience, so I’m tempted to do some refactoring of old code based on what I know now. That has risks, will take time, etc, but will also pay off. Once there are customers it is much harder to be proactive about such. On the other hand, one could tweak working code indefinitely too.

I recall playing scrabble with my father-in-law when I knew there was a good move to make, but I wasn’t coming up with it. So I flipped my letters over and asked the others at the table to help me make the optimal word. Bad move. That wasn’t how my husband’s family played the game. I got the results I wanted and even told them they didn’t have to add it to my score. That wasn’t how they played either. Live and learn. I’ve considered asking if either InterSystems experts or peer volunteers could take a look at our code and make suggestions, but I figure that given that we have tons of suggestions when we look at our own code, that approach would not gain enough right now. Once we have something we think is good, then that might be a better time to ask, but I suspect that would be hard to do for a number of reasons, pride being one of them.

I’ll try to make good business decisions on when to refactor, when to do minor changes to improve such things as variable names since our standards have evolved somewhat. Is it ever a good decision to leave crap code in the software? I hate to say it, but probably. I can certainly imagine a good business decision in some cases will mean that there will still be crap code left after going through and making these changes, but I would prefer that everything be top notch, of course.  Hmmm…decisions, decisions.