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.

Popular posts from this blog

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 and sa…

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 https://github.com/tfnico/config-mr.git 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 operating on many repositories at the same time.

I discovere…

Always use git-svn with --prefix

TLDR: I've recently been forced back into using git-svn, and while I was at it, I noticed that git-svn generally behaves a lot better when it is initialized using the --prefix option.

Frankly, I can't see any reason why you would ever want to use git-svn without --prefix. It even added some major simplifications to my old git-svn mirror setup.

Update: Some of the advantages of this solution will disappear in newer versions of Git.

For example, make a standard-layout svn clone:

$ git svn clone -s https://svn.company.com/repos/project-foo/

You'll get this .git/config:

[svn-remote "svn"]
        url = https://svn.company.com/repos/
        fetch = project-foo/trunk:refs/remotes/trunk
        branches = project-foo/branches/*:refs/remotes/*
        tags = project-foo/tags/*:refs/remotes/tags/*

And the remote branches looks like this (git branch -a):
    remotes/trunk
    remotes/feat-bar

(Compared to regular remote branches, they look very odd because there is no remote name i…

The Best Log Viewer Ever

This is what it looks like when I want to have a look through the logfile, to see what a user did on one of our machines one day:


Read the whole story about how it works on the Viaboxx Systems blog (and upvote on DZone!).

Microsoft ups their Git efforts another notch

This week Microsoft announced first class Git support embedded in the coming version of Visual Studio.

Now, it's not completely shocking. We could have seen it coming since Microsoft started offering Git repos on CodePlex, and more recently offering a Git client for TFS. In any case, these are some big news. Scott Hanselman weighs on some features and some more background here.

For those who are a bit unaware of what the Git situation on Windows looks like these days, I've dotted down these notes:
Some explanation on these:

msysGit has long been The Way to use Git on Windows. It's basically a port of Git itself, so it's a command-line tool.GitExtensions (includes Visual Studio integration), TortoiseGit, Git Shell, posh-git and most other tools are powered by msysGit.libgit2 is a native library for doing Git stuff. It is developed completely separate from Git itself. The above tools could (and should) probably use libgit2 instead of hooking onto and around msysGit.Github…