Sep 29 2004

Conceptual Integrity

I’ve been thinking about conceptual integrity a lot today.

In the 20th anniversary edition of Fred Brook’s Mythical Man-Month he says:

“I am more convinced than ever. Conceptual integrity is central to product quality.”

Furthermore, he says:

“Having a system architect is the most important single step toward conceptual integrity”

As I assess my performance as software architect, I have to take responsibility for bit rot and increased entropy that I see in some of the software and supporting material that’s under my care. It’s easy to get caught up in low-level details and fighting fires when there are time-sensitive issues clamoring for attention. This is the classic tyrrany of the urgent over things that are more important in the long run.

The build process, test coverage, consistent naming, consistent user experience, clear quick start guides… these are all things that require upkeep. This needs to be balanced by the business needs and bottom line of the organization. It’s not good enough to have a big projected positive balance at the end of the quarter/year if your cash flow goes negative before then! And sometimes it makes sense to leverage some technical debt to get a release done before a critical milestone. That’s all part of figuring out the priorities.

I like using the word “integrity” in the context of software development, because it is used in association with both personal integrity and, say, the integrity of a ship’s hull. With a ship’s hull, a breach of integrity is pretty clear and has some direct consequences. Everybody can agree that a breach in the hull’s integrity is a bad thing. (Unless you’re trying to sink the boat!) With personal integrity, the consequences can be just as devastating, but the chain of cause and effect is not as clear. The conceptual integrity of a software development effort can be compromised a little bit at a time, like our personal integrity. That makes it trickier to manage than a ship’s hull, unless the boundaries are clearly drawn. You can say “never break the build” with a good chance that people will understand that clearly. It’s harder to tell people “don’t use stupid names” or “don’t annoy the users” and expect a consistent interpretation. It takes vigilance to keep things on track.

So, I’m renewing my commitment to maintain the conceptual integrity of the software and development process.