Home > management, technical > Where Elitism Is Proper?

Where Elitism Is Proper?


Ever since I stumbled upon Fred Brooks‘s meta-physical idea of “Conceptual Integrity” in his classic book, “The Mythical Man Month“, I’ve strived mightily to achieve that elusive quality in the software work that I do. Over twenty years ago, Mr. Brooks stated that the greatest conceptually integral designs were the product of one, or at most two, human minds. Fred asserts that his “one or two minds” principle still holds true today:

My fictional alter ego, Bulldozer aught aught, would’ve re-worded the beginning of the statement to “Most, if not all… “, but Fred’s message stills rings loud and true.

According to Fred, in today’s world of exponentially growing complexity and team sizes, conceptual integrity is more difficult to achieve than ever:

Why the increased difficulty? Because as a team grows larger, more minds will collide with each other to express and manifest their incompatible design ideas. Big projects can, and usually do, devolve into “design by committee” fiascos where monstrously over-complicated contraptions get created and foisted upon the world.

Ok, Ok, you say. Enough disclosure of the pervasive problem – we get it Yoda. What’s the solution, bozo? Here it is:

Even though it sounds simple to enact this policy, it’s not. The role of “Chief Designer” in a group of highly educated, independent thinking people is fraught with peril. It requires a dose of discipline imposition that can be perceived as “meanness” to external observers. Too much perceived meanness can cause a supporting team to morph into an unsupporting team and lead to the ejection and ostracism of the chief designer. Too little meanness and the possibility of achieving conceptual integrity goes right out the window – it’s Rube Goldberg city. Bummer.

Does your org explicitly recognize and implement the “Chief Designer” role – which is not the same as the softer, less technical, more politically correct, and more administrative “software lead”, “project manager”, “product manager”, and…….. “software rocket-tect” roles? If your org does formally implement the “Chief Designer” role, are your chief designers kept on a tight leash by higher ranking BUTTS, BMs, BOOGLs, SCOLs or CGHs that have no idea what “conceptual integrity” means? Worse, do your “Chief Designers” (again, if you have any) handcuff themselves in order to increase their promotability?

I’m not into corpo caste systems or stratified command-control hierarchies and I struggle endlessly to fight the instinct to play the “I’m smarter than you” game, but I agree with Mr. Brooks when he asserts that world class product design is one of those rare situations…..

How about you? Where do you stand…… or sit?

Note: The snippets in this blarticle were copied and pasted from Fred Brooks’s “The Design Of Design” pitch at the Construx Software Executive Summit. You can download and study it in its entirety from here:  Summit Materials.

  1. SilenceImpliesConsent
    November 23, 2010 at 9:03 am

    Most developers will buy the design integrity argument, but that’s not the same as being willing to sacrifice one’s career prospects for the greater good.
    If you give others a fair chance to prove that they’re worthy to join the elite (and not just the pushy ones) then fine. If you don’t then you’re missing out; furthermore some of your resources will walk if they feel you’re not giving them the chance to show what they’re made of, and that’s probably not what you want.

    • November 23, 2010 at 10:24 am

      Good points. Thanks for the input.

  2. M
    November 23, 2010 at 6:37 pm

    I encountered approximately 1900 students during my career and gotten to know their programming skill intimately and seen them grew up. Out of these, approximately 0.1% has been really talented. To give a metaphor, in maths you can either learn a method or algorithm without actually understanding it to solve problems or you can understand the underlying theory and derive the algorithm or method at need instead of learning to recount all the steps. Given this, I agree with Fred Brooks. Further, I have investigated some truly good software architectures that has been the brainchild of a few really good designers.
    However, a counter argument is that even if you are talented and experienced, you may miss out something vital. So, in my view, leaving design to chief designers is a possibility, BUT it has to be reviewed by a multifaceted group of people (some may not even be software engineer or computer scientists) forcing the chief designers to explain the design.

    • November 24, 2010 at 8:52 am

      I agree with your last paragraph – as long as the reviewers and approvers are peers and not managers or politicians who don’t understand software design. No designs, especially for large systems that are financially or safety critical, should be kept secret. Chief designers, tough or soft, shouldn’t be chief designers if they don’t have open minds and can’t (or don’t want to) disclose their designs effectively.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: