Archive
Fierce Protection
Delicious, just delicious. Pitches from Fred Brooks, Scott Berkun, Tom DeMarco, Tim Lister, and Steve McConnell all in one place: the Construx (McConnell’s company) Software Executive Summit. You can download them from here: Summit Materials.
Here’s a snapshot of one of Fred Brooks’s slides that struck me as paradoxical:
So…. who’s the “we” that Fred is addressing here and what’s the paradox? I’m pretty sure that Fred is addressing managers, right? The paradox is that he’s admonishing managers to protect great designers from…… managers. WTF?
But wait, I think I get it now. Fred is telling PHOR managers to “fiercely” protect designers from Bozo Managers (but in a non-offensive and politically correct way, of course). Alas, the fact that this slide appears at all in Fred’s deck implies that PHORs are rare and BMs are plentiful, no?
How do you interpret this slide?
Infinitely Late
In deference to Fred Brooks‘s “adding more people to a late project makes it later“, I present you with the enhanced version: “adding more people to a late project makes it later, and at some critical size K, adding more people makes it infinitely late“.
As more smart and competent people are added to an org or project, the capability of the group to accomplish great things increases. The really sad thing about poor management is that this increased capability is countered by increased fragmentation and growth in fatty middle corpo layers that slowly snuff out productivity. The lag time between the addition of people and degraded org productivity can be can be so great that the correlation is totally missed and the probability of recovery goes to zero.
At a really dysfunctional institution, productivity plummets to zero and the immobilized institution withers away – unless some sugar daddy starts subsidizing the beast without regard to performance.
In the cases where the hapless institution is a government, it can become is its own sugar daddy. Since it has the bullying power to subsidize itself via taxation of its constituency, it can maintain its comatose state for essentially infinity. DYSCOs are not so lucky. They can, and often do, run out of money before they even know what hit them.
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.
Sacrifice Or Enjoyment?
On the recommendation of Fred Brooks, I read Dorothy Sayers’s “The Mind Of The Maker” after finishing his delightful “The Design Of Design“. TMOTM explores the possible connections and similarities between human and divine creativity. This passage triggered a twinge of gratitude within me.
When a job is undertaken from necessity, or from a grim sense of disagreeable duty, the worker is self-consciously aware of the toils and pains he undergoes, and will say: “I have made such and such sacrifice for this.” But when the job is a labor of love, the sacrifices will present themselves to the worker – strange as it may seem – in the guise of enjoyment. – Dorothy Sayers
Why gratitude? Because I’ve been lucky, incredibly lucky, to have worked on enjoyable projects doing work I love for the vast majority of my career. Oh sure, there were temporary spikes of perceived “poor me” thinking on each and every one of those projects, but at end game, I felt like I contributed something of value while enjoying the work at the same time. I think, but am not sure, that most people can’t quite say that. Some people hate to go to their jobs every single day.
Sayers is an eloquent writer and there’s quite a bit of good stuff in TMOTM, but I felt my mind wandering often. I was too turned off by the religious-specific passages and references. Nevertheless, here are a few other gems that kept me reading till the end of the book:
Every thought is an inseparable trinity of memory, understanding, and will.
The stronger the creative pulse, the more powerful is the urge away from any identification of the ego with creation.
The artist does not see life as a problem to be solved, but as a medium for creation.
Supported By, Not Partitioned Among
“A design flows from a chief designer, supported by a design team, not partitioned among one.” – Fred Brooks
partitioning == silos == fragmented scopes of responsibility == it’s someone else’s job == uncontrolled increase in entropy == a mess == pissed off customers == pissed off managers == disengaged workers
“Who advocates … for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks
Note for non-programmers: “==” is the C++ programming language’s logical equality operator. If the operator’s left operand equates to its right operand, then the expression is true. For example, the expression “1 == 1” (hopefully) evaluates to true.
Knowing this, do you think the compound expression sandwiched between the two Brooks’s quotes evaluates to true? If not, where does the chain break?
The Best Defense
In “The Design Of Design“, Fred Brooks states:
The best defense against requirements creep is schedule urgency.
Unfortunately, “schedule urgency” is also the best defense against building a high quality and enduring system. Corners get cut, algorithm vetting is skipped, in-situ documentation is eschewed, alternative designs aren’t investigated, and mistakes get conveniently overlooked.
Yes, “schedule urgency” is indeed a powerful weapon. Wield it carefully, lest you impale yourself.
Unconstrained To Constrain
As I continue to slowly inhale Fred Brooks‘s book, “The Design Of Design“, I’m giddily uncovering all kinds of diamonds in the rough. Fred states:
“If designers use a structured annotation or software tool during design it will restrict the ease of having vague ideas, impeding conceptual design.”
Ain’t that the truth? Don’t those handcuffing “standard document templates, processes, procedures, work instructions” that you’re required to follow to ensure quality (lol!) frustratingly constrain you from doing your best work?
Along the same lines, Fred hits another home run in my ballpark (which is devoid of adoring and paying fans, of course):
“I believe that a generic diagramming tool, with features such as automatic layout of trees, automatic rerouting of relationship arrows, and searchable nodes, is better suited to (design) tree capture. Microsoft Visio or SmartDraw might be such a choice.”
Man, this one almost made me faint and lose consciousness. I live, eat, and breath “Visio”. Every picture that you’ve seen in this blog and every design effort that I undertake at work starts with, and ends with, Visio – which is the greatest tool of expression I’ve ever used. I’ve tried “handcuffers” like Artisan Studio and Enterprise Architect as software design aids, but they were too frustratingly complex and constraining to allow me to conjure up self-satisfying designs.
All designs must eventually be constrained so that they can be built and exploited for profit. But in order to constrain, one must be unconstrained. How’s that for a zen-like paradox?
The Answer To A Burning Question
Ever since Fred Brooks hatched his legendary “The Mythical Man Month” over 20 years ago, he’s been on my hero/mentor list. His latest insightful work, “The Design Of Design“, is just as good as TMMM. Of course, since my views on software engineering (if it can be called engineering) are heavily influenced by his experiences as shared through his writing, I’m totally biased and unobjective (but….. aren’t we all to some extent?).
I pre-ordered TDOD as soon as I heard about its impending release and I received it from Amazon last week. Unlike most books, which I mildly speed read, I’ve been savoring this one slowly. As expected, I’ve been discovering and extracting a treasure trove of personally valuable fieldstones from TDOD at a feverish pace.
Fred opens up one of his chapters with this brilliant quote:
“A meeting is a refuge from the dreariness of labor and the loneliness of thought.” – Bernard Baruch
I think it’s brilliant because it answers a burning question that I haven’t been able to self-answer for a long time in one short sentence:
Why do managers spend the vast majority of their time in meetings?
Thanks to Fred and Bernie, I now know why 🙂
Conceptual Integrity
Like in his previous work, “The Mythical Man Month“, in “The Design Of Design“, Fred Brooks remains steadfast to the assertion that creating and maintaining “conceptual integrity” is the key to successful and enduring designs. Being a long time believer in this tenet, I’ve always been baffled by the success of Linux under the free-for-all open source model of software development. With thousands of people making changes and additions, even under Linus Torvalds benevolent dictatorship, how in the world could the product’s conceptual integrity defy the second law of thermodynamics under the onslaught of such a chaotic development process?
Fred comes through with the answers:
- A unifying functional specification is in place: UNIX.
- An overall design structure, initially created by Torvalds, exists.
- The builders are also the users – there are no middlemen to screw up requirements interpretation between the users and builders.
If you extend the reasoning of number 3, it aligns with why most of the open source successes are tools used by software developers and not applications used by the average person. Some applications have achieved moderate success, but not on the scale of Linux and other application development tools.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 