When I was in the Navy, I had a friend named Tom. Not only a great naval officer, aviator, and all-around good guy, he was also a good husband. And by good husband I mean that he modified his beloved Ford truck to include a tow hitch for his wife’s horse trailer. It was a big horse trailer and he had to get one of those hitches that was attached into the bed of his truck. It was a major change.
Being the wise man that he was, he went to get some estimates. The first one he got was a reasonable price, but the second one was twice what the first one was. Tom asked why, since the first price wasn’t small, and the second guy’s price was pretty hefty. The guy said “Well, you can pay me to do it the right way, or you can pay that guy and then have your hitch rip off and have your horse trailer go careening off while you are cruising down the highway”. The point, of course, was that there is an upfront cost to doing things right that can prevent even more costs down the road (literally, in this case). Needless to say, Tom went with the second guy.
This quote came from a book I read recently called Code Simplicity: The Fundamentals of Software.
It’s a short book – I read it in a couple of hours – but it is a good one. Full of wisdom about software development, it makes the point that no matter what, your software is going to change. And when it changes, you will introduce defects, so you need to make it as easy as possible to change your code in order to minimize the bugs you introduce when changes occur and decrease the difficulty of adding new features. It’s a really good book – give it a read.
The bottom line of the book is this: In order to manage complexity in the large, you need to code for simplicity in the small. Complexity is the key, and how you manage that will dictate the long-term success of your project. It’s amazingly easy to create complexity, and it takes a lot of work to create simplicity.
So code is like the trailer hitch –- you need to put your costs up front in order to avoid disaster in the future. As Kanat-Alexander says –- we need to put effort into the implementation of our code in the beginning so that costs are minimized during the maintenance period. We need to plan for the long haul, designing our systems up front to be flexible and changeable and composed of simple modules. You can build complexity by combining simple modules into a complex system. Simple modules are easy to maintain. You can also build complexity by combining complex modules, but complex modules are difficult to maintain.
There is no up-side to the “Get it done quick and we’ll worry about fixing bugs later” way of doing things. “You can pay me now or you can pay me later” is how the old saying goes, and it’s as true for software as it is for horse trailer hitches.
Top comments (1)
I felt this contrast today.
I applied a bug fix in our legacy system. Within an hour, I received an email that a different app was now broken. I had to rollback the fix and now wait on an already-pending enhancement on that app which would make the fix compatible.
Later, I received an email of a blocking bug in our new system. (I hadn't actually worked on that app for a few months now, but was being backup for a dev that was out.) I was able to repro it immediately, and had a fix deployed in about 30 minutes, unblocking the user from their work.
The first system made me appear and feel inept at maintenance. The second system made it seem like bugs were rare and maintenance is easy. I helped build both systems. The latter got the benefit of many years experience.