Most programmers are lazy, for some value of lazy. Many of us claim that we are efficient, doing no more than is actually needed, pulling resources from elsewhere, and generally getting things done in time to make it to the pub. Why, then, do we sometimes over-engineer solutions to the point that when we get to the end of the task, we have lost sight of the feature we were building when we began?
I wonder sometimes if it’s because we love to code, so we look for opportunities to put into practice what we have been reading or hearing about lately. If you’ve ever worked on a team with someone who has recently read about design patterns, then you will know exactly what I mean. I am guilty of this too. Sometimes, I find it hard to start simple and get the basics right, and I prematurely optimize for requirements that haven’t materialized yet. Even beyond the realms of software development, this is all too easy to do.
Take, for example, a party that’s happening at my place this winter. Some PHP friends have invited themselves over for a gathering during the festive period. Instantly, my mind jumps to themed menus, rearranging rooms, three-course meals, breakfasts, and home baking. I’m sure that, with all of the above provided, everyone would have a marvelous time, although I’d probably be frazzled if I managed to get all of that done! In reality, spending three days in the kitchen is not what is called for here — the friends are coming to see one another, and they need something to eat while they are here. A tasty casserole (someone else is bringing pudding), a pile of clean towels, and toast for breakfast the next day meets the requirements, and an equally marvelous time will be had by all.
When building software features, overdoing it is just as bad as the martyr at Christmas who cooks too many things and expects praise for over-feeding everyone. One of the values of the extreme programming movement is the pledge to “code for today.” This means only create what we know today that we need, not to spend project time on something that we think might come up in the future. When additional requirements come into scope, we can refactor as we need to. In a real-world software project, an overdone solution increases complexity and maintenance burden. As a result, it is tough to justify.
So, think carefully as you build your software (or plan your party) this Christmas. Could this be simpler? Keep taking things away until all that remains is what is actually required, and build only that. Merry Christmas, one and all, and here’s to a new year of sweet and simple solutions that are easy to take care of for a long time to come!
