Builders, programmers, and the costs of rewriting software systems.
I love a good builder analogy when it comes to software development.
Often when talking to business stakeholders it is useful to use terms that they are familiar with and concepts they can easily grasp and are analogous to those we use in developing software. As software developers, we are skilled tradesmen. We have years of training to develop the skills needed to build projects up from a greenfield site to something of value. We build with bits and bytes rather than bricks but often our concepts can be very similar.
A typical analogy I use is to explain why it takes longer to rewrite a badly constructed, poorly performing software project again from scratch than it did to write the software first time round.
Take it you had a garage built onto the side of your house. The builders you had in to do the job didn’t build the foundations properly. It looked a bit of a shoddy job, but you had invested a lot of money in it so you put up with it. A few years later, there are severe cracks showing in the walls, you know that it won’t last much longer, and so you bring in another builder to help you with it.
He tells you that it all needs to come down because the foundations are really poor, and we need to build the whole thing again. However, this time it will take a lot more time and cost a lot more money. Why?
One reason is that over the last couple of years you have integrated the utilities of the main building into it, running electrics, water, and waste through the extension, and all these need to be resolved. You’ve also added a further bedroom extension on top of the garage and so you not only have to rebuild the garage, but rebuild that too. In addition, all of these things are constantly in use – you need the garage for your vehicle, and the bedroom is your daughter’s room.
Software projects are often very similar. You have a legacy system with a fundamentally bad design which is causing massive problems within your business, and the only recourse, due to that initial poor design, is to do it again. However, since the software was first written you now have various integration points (the utilities) and other subsystems which look like they may not need rebuilding but rely directly upon the code in the badly performing system (the daughter’s bedroom). In addition everybody in your business needs to keep using these systems whilst they are changed over and will need training upon the new system, plus any data migrations need to take place to enable the move to happen easily.
Frequently, the subsystem also has to be rewritten with very little input from the end users, who may have been heavily involved in the original development, but now don’t have the time or the inclination to be involved in a technical rewrite. Original requirements documents, if they exist, are rarely useful, as during the process of development the requirements change and documents are rarely kept up to date. Imagine rebuilding the garage and the bedroom above it with little to no involvement from the homeowner to ensure they will be happy with the finished product!
Due to budget limitations, sometimes the only feasible way forward is to attempt remedial measures. Put in some props, dig some trenches around the foundations and pour in some concrete. This leaves you with an ugly mess, but at least the house won’t fall down!
Business stakeholders can often be bamboozled by technical talk, but the principles of constructing software are similar to any project that takes a concept from design through to completion and use.
