We've long been told that we need to be thinking outside the box to avoid getting caught in the traps and problems that typically appear when we plod along through things doing them the same old way and making the same mistakes that we always collectively make. I, your humble narrator, agree that this is indeed Sage And Great Advice.

BUT!

I feel that sometimes we work so hard making sure that we are thinking outside of one box we end up putting ourselves in another box with its own confusing, harsh, and this time more surprising set of problems. After all, we were thinking outside of the box -- why are we in another one?

In case you haven't guessed where this is going, this entry is another in my line (does a pair make a line? Note to self: find out.) of posts supporting the idea that imposing a set of constraints on yourself -- in this case working within the box -- can often free your mind to worry about other and more important things. Ken Arnold agrees with me, and Joel Spolsky agrees with him! *Even though they both thought so before I wrote any of this!*

I got to thinking about all this because I was recently writing a little game for my new Android phone (here is a little applet version! Based on simple-tetris-clone) and realized that I enjoyed all of the constraints (framed as Best Practices) that the folks at Google recommended we work within and follow. While I obviously didn't create a masterpiece of coding and design (at best, it's a mediocre clone), I still really enjoyed my coding experience and the creativity I had to use to tackle some of the issues within the set of constraints of the system. I continue to think that by embracing the limitations of these boxes we find ourselves within, we can come up with clever and creative solutions to problems that arise within this system.

In this scenario, I perhaps didn't have or want an opportunity to "think outside the box" and drift from the constraints of the system since part of my goal was to learn about the new platform and its best practices. However, had I decided to avoid the recommendations of the best practices and come up with my own scheme for something, I'm sure I would have run into some roadblocks that I avoided by focusing my energies on solving problems from inside the box.

Labels: ideology, opinion, ramble

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