What follows is a totally fictional dialog. It’s the kind of conversation that might happen several times a week on a software team as a release nears.
Hacker, speaking to co-worker, announces: “There’s no way to make these buttons invisible. They’re initialized by an array that gets set before the screen is displayed. … So I’m just going to disable them instead.”
Co-worker: “But isn’t there a way to remove the buttons?”
Hacker: “There’s a way to add buttons. … I think it’ll just be easier to disable them.”
In walks Subject Matter Expert (SME) who, after overhearing this conversation, points out: “There’s another screen that does that, it’s probably a good example to use.”
We have reached an inflection point: Does the Hacker go with the technique he figured out after spending quite some time tracking down the issue? Or does he take the SME’s advice and use the approach used by other screens?
There are many things to be gleaned from the Hacker’s decision that directly bear on how well the software he builds will stand the test of time.
Abandoning an approach that you’ve invested in does not come naturally. In fact, in other areas of life it’s what you’re not supposed to do. It’s hard for us even to detect how attached we are to an approach and how that attachment influences our judgment or willingness to abandon it. But when it comes to software design, like any other exploratory activity, being able to recognize a dead end quickly is crucial to delivering quality on time.
Even though it doesn’t come naturally I’ve found that it does become easier with practice. Once you’ve done it a few times and, more importantly, reaped the rewards of a system that either functions better or is more easily maintained (or both), those benefits make it easier to swallow the next time.