On ensuring conceptual integrity in systems design

Fred Brooks outlines 3 essential points about systems design:

• Conceptual integrity is the most important consideration
  
• Deciding precisely what to build is the hardest part


• The focus of any organizational structure must be on solving the critical need for communication

Some of these depend on each other, which can be represented graphically:


Of course, you can't just do these things in order. Over the course of everyone actually building the thing, decisions about what it will do must be revisited.


So, to make a great system, first one must decide what it will do, then ensure that its concepts remain coherent, then communicate constantly and easily with everyone building it. At Treemo, I sit right at the second step in that list, and am working on becoming better at the third, as it is increasingly required of me.

Anyway, these concepts are software engineering 101. Every tool, process, idea, program, or proposal that crosses my desk is going to have this diagram applied to it. "Does this thing solve a communication problem and/or reinforce our software's conceptual integrity?" It seems simple, but most things don't pass. Sometimes I feel like people turn their brains off when evaluating things like this. Software is hard, yes, but process of making it is over 50 years old, and the thousands of software projects that have lived and died in that time can tell us a LOT about how to make solving that hard problem easier. We have such ignorance of our history in this industry. I've only been a professional developer for a year now, and I've reinvented hundreds of wheels both in my code and in my organization. It's exhausting sometimes.

Also worth addressing are the blocks on the bottom of the first diagram: transparent trust, shared vision, and sharp tools.

First, you're not going anywhere in any company if you can't trust those around you. The need in software for fluent, open communication cannot be met without grab-my-hand-over-a-cliff trust. Joel is right about this, even though he doesn't come out and say it. Gifting your developers with offices, decision-making authority, and free lunches is a wonderful way to create a safe environment where they feel free to create and speak.

Second, everyone making software must grasp their role in both the company and the development process. They must share that vision for their role and be enthusiastic about it, because if they're not, why are they working there? Being on-message is just as important for testers as it is salesmen.

Finally, sharp tools must be available to everyone who needs them. Michelangelo was known to work so quickly and so hard that he would work all night with a candle on his head, chiseling furiously until the marble dust choked the air of his workshop. How many chisels do you think he owned? When you look at the David, do you wonder at how much he spent on having them sharpened? This also ties in with the trust issue: put a fast computer in that office.

Now, to build a company wise enough that I don't have to spend Sundays thinking about this stuff...