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

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

Using Voice-Chat for Gamers in Distributed Teams

This is a post going into the usefulness of live voice-chat tools in distributed teams. If you've ever seen the Leeeeeroooooyy Jeeeenkiiins video of World of Warcraft fame, you've heard this kind of tool in action. It's how the participants in the video are speaking with each other - this is not a feature built into the World of Warcraft game - it's a separate team-oriented VoIP software, and it's all about letting gamers communicate orally while gaming.  Since these tools are for gamers, they have to be fast (low latency) light (as not to steal CPU-cycles from heavy games graphics)  moderate in bandwidth usage (as not to affect the game server connection) There are several options around: TeamSpeak , Ventrilo , more recently the massively grown Discord , and finally Mumble , which is the open-source alternative of the gang. A few years ago, when I joined eyeo (a distributed company), several of the operations team were avid gamers, and had a TeamSp

Joining eyeo: A Year in Review

It's been well over a year since I  joined eyeo . And 'tis the season for yearly reviews, so... It's been pretty wild. So many times I thought "this stuff really deserves a bloggin", but then it was too inviting to grab onto the next thing and get that rolling. Instead of taking a deep dive into some topic already, I want to scan through that year in review and think for myself, what were the big things, the important things, the things I achieved, and the things I learned. And then later on, if I ever get around to it, grab one of these topics and elaborate in a dedicated blog-post. Like a bucket-list of the blog posts that I should have written. Here goes: How given no other structures, silos will grow by themselves This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders. I've worked in silos, and in companies wit

The End of GitMinutes (my podcast)

I'm just about ship GitMinutes episode 46, which is going to be the final episode. I'll just paste the outro script here, as it sums up the sentimental thoughts pretty well: I’m happy to have finally finished [publishing the last episodes from Git-Merge 2017], just in time before Git-Merge 2018 takes place in March. I won’t be going there myself, so I’m counting on someone else to pick up the mic there. It’s sad to be shipping this one as it is probably the last GitMinutes episode ever. To go a bit down memory lane, 6 years ago, my daughter was born, and as I used a little of that paternity leave to set up my podcasting infrastructure and produce the first few episodes. Initially it was just going to be 10 episodes and call the experiment finished. Instead, I got to 46 episodes, the last dozen or so lazily tailing the last few Git-Merge conferences. To every one of my guests, thank you so much again for coming on to share your passion in this little niche of computer s