Paying Code Tax
A couple of weeks ago I began working on a somewhat sizeable software development project. It started out as a proof of concept – a one file program to see if something was even possible (it was).
Over the days that followed the file grew exponentially as I fleshed out the code, built a user interface, and so on. Slowly but surely the entire thing became a bit of a nightmare to work on – the words convoluted, messy, and disorganised come to mind.
There's an old maxim related to software development, that I think comes from the open source community – stating that you should factor in a sensible percentage of your time to re-do, re-write, and re-organise code as you go forwards with a project. It's commonly called “code tax”. Not everybody does it, but it's a good idea.
I spent today splitting one file into many, and breaking discrete areas of functionality into separate objects with properties and methods. It took all day, and yet the client will see no immediate benefit because the end result is a piece of software that appears to work identically.
The benefit comes a year from now when the software has grown exponentially, and has perhaps been handed over to other developers. Not only can it be extended easily, but the code is easy to follow, easy to debug, and easy to test.
So yeah... code tax. Expensive, but worth it in the long run.