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.

Labels: ideology, programming

I'm a fan of pretty much all of the advice and ideas contained within the hallowed leather bound pages of The Mythical Man Month by Fred Brooks. If you haven't read it and are even the least bit involved in software engineering, I recommend checking it out or at a minimum reading the Wikipedia article summarizing its main themes.

One of the most important essays is about how to best organize a team when developing a system. Using a surgical team as a metaphor, Brooks recommends having one chief surgeon that leads the team, does most of the critical work (and planning beforehand), and directs the rest of the team to perform the ancillary tasks required to complete the surgery efficiently. This ties in directly, I believe, with his claim in an earlier essay that the most important trait of a successful project is one that has conceptual integrity, which can most realistically be achieved when only one or two people are in charge of designing a system.

We try to stick to this philosophy here at WAM. Often times, even when we have a new idea to add to X2O, Ka Wai and I will discuss its merits and whether the features fit the arc of the system's reason for existence. I've referred back to a one-page write up that Ka Wai (the architect behind X2O both in name and function) wrote up a long while back to see if the new additions I may have in mind square with the essence of X2O. Sometimes, a feature may not make it out the door because it isn't necessary or it adds complexity at too high a cost. Sometimes, it breaks the experience a user has with the product. Whatever the reason, the end result is a product that remains focused and fit.

While some people may cringe at the thought of a chief designer (be it surgeon, architect, or engineer), believing that they will be stifled by such limits on their ART, systems are always better off for having one; they enable developers to use the full power of their mind, creativity, and imagination roam free within the borders defined by the designer. Constraints allow you to learn new, more efficient ways of reaching goals that would otherwise have been achieved in a way that likely would've broken the integrity of the system.

While sitting around with friends back in my teenage heartthrob days staring at the stars, joking and rambling on about nothing in particular was worthwhile and meaningful in its own way, no tangible problems ever got solved -- which isn't what that kind of freedom is best suited for anyway. Instead, I feel that it is best used for brainstorming ideas, developing concepts, and inspiring new thoughts in general; in the world of system and software design, this kind of thing should happen before any project gets underway, not in the midst of working on a real task.

Lastly, having a concept from the start forces you to design your system ahead of time and plan every aspect of the system, including how and under what circumstances it can change. Plans make the point of all this work transparent to all members of the team, and likewise, team members' thoughts focus on the core meaning behind the system. Additionally, transparency has a tendency to reduce confusion and stress among a team, since nobody can let their mind wander and get distracted from the fundamentals of the system. As someone once said, "When being naked is the norm, fitness is no longer optional."

Labels: mythical man month, organization, programming, ramble, team