A Rambling Post About Some Kinda Naked Surgeon…

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.”