Coding Is Like Cooking

This week I was finally invited to the architect forum meeting. Ten more or less geeky men, and me. It’s funny, I don’t usually think about the gender imbalance in the software industry much. On this occasion though, I felt distinctly uncomfortable. They all seemed to know each other, and mostly ignored me. They had an annoying habit of spattering their conversation with unidentified acronyms. I left feeling somewhat disheartened.

Later that evening I talked to my husband about the experience, as I often do. Seeing as we both work in the same industry, he generally has helpful comments. This was no exception, even though Geoff is currently at home with the children, enjoying his parental leave. “I understand just how you feel. Today I went to the baby rhythm and song group. Ten women with babies, and me, also with baby. They all seemed to know each other, and mostly ignored me. They tended to talk about breastfeeding and shopping.”

So it could be worse, I suppose.

What is the quality of this codebase on a scale of 0 – 100? Zero means “perfectly designed, clean code” and 100 means “total spaghetti, impossble to make changes”.

Without hesitation, Andreas answered. “70”.

Andreas was standing at the whiteboard, sketching a timeline and drawing boxes labelled with the names of the parts of the system and the people involved. His task was to give a history lesson to the latest batch of newly arrived programmers. How did we get here?

It seems that way back in about 2001 when Andreas and the rest of the team of hotshot young programmers began building this system, it was pretty good. In six weeks ten programmers had achieved more than 100 consultants from had achieved in 3 months. That code was ditched shortly afterwards and Andreas’ team code is still at the heart of the system today.

It seems that for several years things went pretty well, Andreas’ team grew slowly and the system gradually took on more and more functionality. Their focus was on working closely with the business and delivering value quickly. The team was so successful that it started pulling back work from the firm’s outsourcing partners, since they were so demonstrably better at delivering valuable functionality quickly.

Unfortunately the programming team is not so productive now. Over the last few years more and more people have been added, a fourfold increase in fact. Many of the original team have either left or disappeared on protracted parental leave. The quality of the codebase has deteriorated as developers unfamiliar with it have implemented new functionality at cross purposes to the original intent. It’s not that they are bad programmers, but rather without guidance from more experienced people it is very hard to introduce new functionality cleanly without breaking anything. The almost total absence of automated tests doesn’t help either. Programmer productivity is dropping steadily.

There are various initiatives to improve the situation. For example, Andreas’ training courses for new programmers. Also, several experienced programmers are working on refactoring projects. (Without the aid of tests). The question is whether this is too little, too late. Rumour has it that the size of the codebase has increased 25% in the past 6 months. Emergency patch releases are now routinely scheduled after every major release. Obvious bugs have are present in the production system that no-one seems to know how to fix.

So the question I really want Andreas to answer is not the absolute quality of the codebase, but whether the quality is increasing or decreasing. Unfortunately, he couldn’t tell. I fear the worst.

My cousin held out the keys to his flashy looking sportscar and said “Do me a favour. If you crash into something with my car and it’s nearly written off, but not quite. Please back up then hit it again, harder, until it really is written off”. I laughed nervously. “yeh, sure. Of course”. Needless to say I returned his car in perfect condition a few hours later.

The architect grinned as he reviewed my design proposal. “Don’t worry about making the code beautiful, just make your changes work without causing extra test cyles. In fact, ugly changes are better. The sooner this code becomes legacy, the sooner we can rewrite it” I laughed nervously. “Sure, of course” He handed back my uml diagram and I went back to my computer to write some code. Beautiful code. Carefully.

For those of you who read Swedish, I have a new post up on jsolutions.se. The gist of it is that I usually read infoq to find out what is going on in the world, and I’ve just realized how biased it is compared with other Java news sources.