Archive for October, 2008

The full programme for SDC2009 in March will be published in about a week’s time, but I can already tell it will be a great event. The call for papers is now closed, and the website has been updated with photos of all the booked speakers. With only one day of talks, it looks like there will be a lot to choose from.

I’m really looking forward to hearing international software gurus like Jeff Sutherland and Neal Ford, as well as lots of cool people from Scandinavia. Clicking through the photos on the front page, there are several faces I recognize as leading agile proponents. It’s actually a bit of a shock to see my own headshot there in the lineup.

The second official meeting of the Gothenburg Python User Group was last night. Eight of us turned up, despite my writing the wrong address on my meeting invite. (It is Norra Ă…gatan 10A, not 6A – sorry!)

Anyway, in the first part of the meeting Jacob Hallen explained about PyPy, a very interesting project. It seems PyPy aims to replace jython, iron python, stackless and a host of other things, and has nearly as good performance as cpython. Jacob reckoned it would be ready for general use in about a year’s time.

After fika, Johan gave a short presentation about how he uses Python at Nordea. Although the company policy is only to use Java and Cobol, he has had some successes with using python too. He’s written several small applications that have been quick and cheap to build and have lasted much longer than their initially projected lifetimes. Unfortunately he hasn’t persuaded anyone else at Nordea to write any python yet.

The coding challenge for the evening was KataRomanNumerals which went very well. We split into four groups and in less than 45 mins three of the groups had working solutions, all different, all elegant in their own way. My group was the one that didn’t come up with a solution and that was because I was more interested in how to define the tests than how to define the solution 🙂 I wanted to write the tests in a spreadsheet then generate unittest test cases. It kind of worked. I will try again another time with FIT instead.

Most importantly, everyone said they enjoyed the evening and the chance to write some python code, just for fun.

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.