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.
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.
Good points. Thanks for the input.
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.
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.