Back in college, one of the most — maybe THE most — important thing I learned about programming was, “code for change.” That was back before OOP and stuff, when the mantra was rephrased as “design for change.” Or maybe I’m getting it all mixed up and I read “design for change” after college and never heard “code for change.” It doesn’t really matter, because I have a different point to make anyway.
I used to look at a software solution that was elegant and beautiful in its complexity and think that was Goodness. I used to write software like that. It worked well, lasted long, and was hell to pass on to “the next guy” to maintain. Then, one day, I set up a mini-lab in the office suite at work to run some experiments on a beautifully complex and elegant bit of software and discovered two things:
- it was so complex that the developers seemed to have run out of time or money or both, and there were loose ends that they told me they thought were best, after all, left loose
- it was doing several things the system it ran on would already do just fine without it.
Well, there was no way I was going to be digging around in all the complicated guts of that software (it is open source) to finish what was decided would be left undone. So, I went back to the drawing board and re-designed the solution without it, based on the realization expressed above in bullet #2. And what happened?
The resulting solution is elegant and beautiful in its simplicity, it works very well, and has lasted a long time. It will also be easy to pass on to “the next guy.” The overused expression “keep it simple stupid” is not really overused, it is merely under-observed. While complexity probably cannot be avoided in programs of any appreciable size, or richness of features, or ease of use, I think that remembering to “keep it simple as possible stupid” is apt.
And that brings me back around to designing for change. If you can keep in mind that someday someone (probably you) will have to change that code, you’ll opt for the simpler, more clear design. If you do the discovery and design phases well, then it should be a (in the world of IT) long time before that happens. So, when it does, you’ll thank yourself that you kept it simple for the distant day in the future that arrived and you were stupid. Stupid in the since that you completely forgot through the mists of the ages since you wrote it how it works. You have to re-discover what you once invented, probably under the gun of something “urgent,” and you’ll be thanking the past you who kept it simple and coded for change.