Real life coding

Software Projects are like 18-wheel trucks

The business of writing software is full of folk who just want to delete it all and start over so it can be done “properly” (where “properly” => “written by me and not someone else”). Most of the time this is a bad idea; rewrites cost a lot and have a reasonable chance of being worse than the original (which has often had time to mature).

Writing a large software project is like driving an 18-wheeler truck in the fast lane. When you start to sense that something isn’t going quite right and you want to pull over and check, what do you do? If you wrench the steering wheel over to full lock, you’re likely to crash and burn. You have to steer gently; ease the truck with its momentum slowly over to where you want to be.

It is usually much better to go for incremental change; baby steps to get to the end result.

Analogy: You’re far less likely to paint yourself into a corner if you only paint a little bit of the floor at a time and leave it to dry before starting the next bit. The size of the area covered each time is a matter of judgement, but should be less than the width of your stride.

Rewriting a smaller subset of functionality will allow you to leave the original in place and swap between the two versions with compiler switches. This allows you do make direct performance comparisons. Alternatively by leaving the original code in place you can compare both versions using unit tests.

If you replace a smaller subset of functionality and it doesn’t work out well, it’s much easier to roll back to the original.

Moving in small steps makes it much easier to keep track of progress and makes it easier for the assigned developers to understand the process, making it easier to check for problems as they code.

You can interleave rewrites with bug fixes and new features in your software, so your product doesn’t “stand still” during a rewrite and users won’t start to feel that it’s old and not updated much.

From a marketing perspective, rather than seeing just one announcement of “we’ve made it better” for a whole rewrite, they will see a series of “we’ve made this feature better” announcements that make them feel you are working hard for them. Your marketers can use this for extended marketing exposure.

When I make recommendations for adding a new technology to a system or for an improvement to existing functionality, I always map out a gentle path to move from where we are now to where we want to be. This lets project managers decide whether to do it all at once, or whether to spread it out over many iterations.