Skip to main content

Legacy Code, Broken Windows and Code Quality

Long time since last post. It's not that I have been particularly busy, just haven't had anything *that* interesting to write about. Well, this might be interesting:

I know this legacy system. Well, it's not that much of a legacy system, it's barely a couple of years old. But it sure didn't take it too long to become difficult to maintain. Maybe you've seen similar scenarios... A big team of developers and consultants with lots of funding creates a big-bang super solution. Struggling to reach a deadline, at some point quality was left behind (or post-poned). We're talking compiler warnings, copy/paste code, hacks, quick'n'dirty (quoting Uncle Bob: There is no quick'n'dirty. Dirty means slow.), bad object-oriented design, the lot.

Well, I have to say that 80% of the code was golden: agile method, top of the line modern open source lightweight technologies, test-driven development, code reviews, continous integration, etc. But that last 20% of patchwork really was the start of things getting worse. We did have this great plan prepared for how we would get things right as soon as we reached the deadline, oh yes, we were going to make everything right again.

So we made the deadline and the project was a huge success. And what happened? Business people were happy and choffed all the consultants out. One maintainer was left behind to do "critical bug fixes". The broken windows remained and the make-things-right-again-plan was buried.

So a year went by. Business decided the solution needed new features. The maintainers desperately tried to keep up with business demands, again consultants were hired to satisfy the need for new functionality. This time, with developers unfamiliar with the existing code-base, more patch-work was done. The coding standards, patterns and technologies were unknown, unclear or inconsistent.

The existing broken window code had a devestating effect on the work that was done by the new consultants, and of course they were under the same pressure from the business-people, if not more. At the same time the maintainers were trying to do bug fixes in parallell, so the code was branched for several months. Upon merging again, the codebase suffered from alot of conflicts, but still the team didn't dare roll back to the stable code-base. The merge had to be used. It took several months of heroic effort from the maintainers (again, the consultant were choffed out prematurely) to get the codebase stable again, adding up to a total of 6 months without releases in a business critical system. That's 12 sprints the way we counted them.

I suppose scenarios like these end up with the system slowly decaying into the awful legacy system everyone loves to hate until finally its decided to be replaced with an all new big-bang system. And so the circle continues..

But not this time! The business has for some mind-perplexing reason actually realised that there is money to be saved from restoring the quality of this system! There will be a series of iterations were the focus is to rid the system of its technical debt (man, I love that term). Of course some business value will be delivered in each iteration, but hopefully this time quality tasks will be top priority.

The moral of the story comes two-fold:

1) Business-people can be taught the value of software quality. They can understand broken windows, it just takes alot of time to get it into their heads. Keep trying. Use good arguments, references and your experience (if you have any), and convince them that quality is the most pragmatic and profit-bound way. And if the project manager won't listen, go to the one above him and tell so. If they won't listen, find another place to work.

2) As a professional programmer, it is your duty to follow a respectful amount of common sense of ethichs and software craftmanship. Listen to the tiny voice inside your head saying "this code stinks" and never leave it behind before the little voice says "this code is good enough".

I've had it with people who write lousy code, calling themselves "pragmatic". From now on, I want to be an idealist :)

I'll finish off with another Uncle Bob quote (or maybe it was Jeff Atwood, good blog btw):

Always leave the code better than when you found it.

PS: This post was actually going be about how I wriggled around with Scala yesterday, getting my project to build Scala with Maven and still work on it from Eclipse (got it working somewhat but not 100%). Appearantly I have forgotten everything I learned about functional languages in Uni (ML), but I have a feeling this approach *might* be the easiest path down the concurrency landscape to come for us Java devs.


  1. Very nice post Thomas!

    Quality matters! It's never too late to make it better, even not when it is just a little tiny bit.

    Uncle Bob also said: Never check in bad code!



Post a Comment

Popular posts from this blog

Open source CMS evaluations

I have now seen three more or less serious open source CMS reviews. First guy to hit the field was Matt Raible ( 1 2 3 4 ), ending up with Drupal , Joomla , Magnolia , OpenCms and MeshCMS being runner-ups. Then there is OpenAdvantage that tries out a handful ( Drupal , Exponent CMS , Lenya , Mambo , and Silva ), including Plone which they use for their own site (funny/annoying that the entire site has no RSS-feeds, nor is it possible to comment on the articles), following Matt's approach by exluding many CMS that seem not to fit the criteria. It is somewhat strange that OpenAdvantage cuts away Magnolia because it "Requires J2EE server; difficult to install and configure; more of a framework than CMS", and proceed to include Apache Lenya in the full evaluation. Magnolia does not require a J2EE server. It runs on Tomcat just like Lenya does (maybe it's an idea to bundle Magnolia with Jetty to make it seem more lightweight). I'm still sure that OpenAdvant

Encrypting and Decrypting with Spring

I was recently working with protecting some sensitive data in a typical Java application with a database underneath. We convert the data on its way out of the application using Spring Security Crypto Utilities . It "was decided" that we'd be doing AES with a key-length of 256 , and this just happens to be the kind of encryption Spring crypto does out of the box. Sweet! The big aber is that whatever JRE is running the application has to be patched with Oracle's JCE  in order to do 256 bits. It's a fascinating story , the short version being that U.S. companies are restricted from exporting various encryption algorithms to certain countries, and some countries are restricted from importing them. Once I had patched my JRE with the JCE, I found it fascinating how straight forward it was to encrypt and decrypt using the Spring Encryptors. So just for fun at the weekend, I threw together a little desktop app that will encrypt and decrypt stuff for the given password

What I've Learned After a Month of Podcasting

So, it's been about a month since I launched   GitMinutes , and wow, it's been a fun ride. I have gotten a lot of feedback, and a lot more downloads/listeners than I had expected! Judging the numbers is hard, but a generous estimate is that somewhere around 2000-3000 have listened to the podcast, and about 500-1000 regularly download. Considering that only a percentage of my target audience actively listen to podcasts, these are some pretty good numbers. I've heard that 10% of the general population in the western world regularly listen to podcasts (probably a bit higher percentage among Git users), so I like to think I've reached a big chunk of the Git pros out there. GitMinutes has gathered 110 followers on Twitter, and 63, erm.. circlers on Google+, and it has received 117 +'es! And it's been flattr'ed twice :) Here are some of the things I learned during this last month: Conceptually.. Starting my own sandbox podcast for trying out everythin

The academical approach

Oops, seems I to published this post prematurely by hitting some Blogger keyboard shortcut. I've been sitting for some minutes trying to figure out how to approach the JavaZone talk mentioned in my previous blog-post. Note that I have already submitted an abstract to the comittee, and that I won't publish the abstract here in the blog. Now of course the abstract is pretty detailed on what the talk is going to be about, but I've still got some elbow room on how to "implement" the talk. I will use this blog as a tool to get my aim right on how to present the talk, what examples to include, what the slides should look like, and how to make it most straightforward and understandable for the audience. Now in lack of having done any presentations at a larger conference before, I'm gonna dig into what I learned at the University, which wasn't very much, but they did teach me how to write a research paper, a skill which I will adapt into creating my talk: The one

Managing dot-files with vcsh and myrepos

Say I want to get my dot-files out on a new computer. Here's what I do: # install vcsh & myrepos via apt/brew/etc vcsh clone mr mr update Done! All dot-files are ready to use and in place. No deploy command, no linking up symlinks to the files . No checking/out in my entire home directory as a Git repository. Yet, all my dot-files are neatly kept in fine-grained repositories, and any changes I make are immediately ready to be committed: config-atom.git     -> ~/.atom/* config-mr.git     -> ~/.mrconfig     -> ~/.config/mr/* config-tmuxinator.git       -> ~/.tmuxinator/* config-vim.git     -> ~/.vimrc     -> ~/.vim/* config-bin.git        -> ~/bin/* config-git.git               -> ~/.gitconfig config-tmux.git       -> ~/.tmux.conf     config-zsh.git     -> ~/.zshrc How can this be? The key here is to use vcsh to keep track of your dot-files, and its partner myrepos/mr for o