Fixing software problems after the fact

It’s better to finish something that’s not quite right than to continue to tweak and tweak the unfinished piece. It’s much easier to go back and fix something that’s “done” than to finagle with nuances of something you’re still working on.

The emotional value of finishing is underrated
Too often, we underestimate the emotional and motivational value of work that is simply…done. Perhaps, it’s not the end-all final product. Perhaps there are tectonic changes to be made. But the mental lift-up of knowing that an execution is complete is largely underrated.

Programmers and designers don’t usually talk about emotion because it feels like a weak excuse, but it’s apparent in everyone I’ve ever worked with – most notably myself. The good feelings of getting things done have huge implications on how well and how efficiently you continue to do your work. The bad feelings of tweaks during development and building software still not graduated from “idea-mode” have an equally negative impact.

The perceived problems of changing functionality is overrated
At the same time, the perceived headaches of trying to tweak functionality after the fact, even deeply rooted functionality, is entirely overrated. The reality is, very few add-ons, removals, or logic shifts are undoable. Good programmers prepare themselves for this anyways. The basis of design patterns and best practices is largely to accomodate for the very real fact that what your code is doing today will likely get tweaked (endlessly) tomorrow.

Iterative development is the antidote to this problem in some ways. It gives developers a taste of being done each time an iteration is released and clients the privilege of tweaking at frequent pitstops along the road to the perfect end-product. Yet, iterative development still works too largely in favor of the latter. It quickly starts feeling like the finish line is a long way off.

It works both ways
Finishing a flawed product isn’t just for the sake of the developer either. It’s so much easier to see what you really want to change, what’s clearly important and what isn’t as important as you thought when you see something in its current “final” state. There are no more what-ifs, there are only yesses and nos. Something does or doesn’t work like you really want it to. These are things that a developer can take back to the shop and change.

I’ll take a completely solidified, 90% correct concept over a 90% solidified “perfect” idea. Going back and correcting completed software is far more palatable than the two-steps-forward-one-step-back dance of code that’s trying desperately to finish itself and be perfect at the same time.

The Cowboys spent $1.2 billion on this strategy
I wouldn’t apply this methodology to all industries – like real architecture for instance. Yet, sometimes it happens anyways.

The new Dallas Cowboys stadium (at a cost of $1.2 billion) has a major flaw. At just 90 feet off the ground, punters are finding they can easily hit the $40 million, 11,520 square-foot scoreboard. If Cowboys Stadium were code, we could easily adjust the scoreboard height. In real life, it’s a multi-million dollar job.

Their solution? The NFL has instituted a new do-over rule on punts that deflect off the scoreboard. I’m not sure if I’m completely happy with a rule that sounds like 6th grade gym class, but, it’s a simple change that costs $0.

If league officials had cared about this detail before the stadium was finished, the Cowboys would likely be taking snaps at the Wal-Mart parking lot across the street this Sunday.