Archive

Posts Tagged ‘Fred Brooks’

The Promotion Strategy

February 18, 2016 Leave a comment

On the left side of the following figure, we have a typical mega-project structure with a minimal Overhead-to-Production personnel ratio (O/P). If all goes well, the O/P ratio stays the same throughout the execution phase. However, if the originally planned schedule starts slipping, there’s a tendency of some orgs to unconsciously exacerbate the slippage. In order to reign in the slippage via exercising tighter control, the org “promotes” one or more senior personnel out of the realm of production and into the ranks of overhead to help things along.

moreoverhead

By executing the “promotion strategy“, the O/P ratio increases – which is never a good thing for profit margins. In addition, the remaining “unpromoted” senior + junior analysts and developers are left to pick up the work left behind by the newly minted overhead landlords.

So, if you’re in the uncomfortable position of being pressured to increase execution efficiency in order to pull in a slipping schedule, you might want to think twice about employing the “promotion strategy” to get things back on track.

The brilliant Fred Brooks famously stated something akin to “Adding people to a late project only makes it later“. In this infamous post, dimwit BD00 states that “Promoting personnel from production to overhead on a late project only makes it later“.

The Annihilation Of Conceptual Integrity


When a large group or committee is tasked with designing a complex system from scratch, or evolving an existing one, I always think of these timeless quotes from Fred Brooks:

“A design flows from a chief designer, supported by a design team, not partitioned among one.” – Fred Brooks

“The entire system also must have conceptual integrity, and that requires a system architect to design it all, from the top down.” – Fred Brooks

Who advocates … for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks

“A little retrospection shows that although many fine, useful software systems have been designed by committees and built as part of multi-part projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.” – Fred Brooks

Note Fred’s correlation between “conceptual integrity” and the individual (or small group) for success.

C++ is a large, sprawling, complex, programming language. With the next language specification update due to be ratified by the ISO C++ committee in 2017, Bjarne Stroustrup (the original, one-man, creator and curator of C++) felt the need to publish a passionate plea admonishing the committee to “stop the insanity“: Thoughts About C++17.

No Longer Cpp

By reminding the committee members of the essence of what uniquely distinguishes C++ from its peers, Bjarne is warning against the danger of annihilating the language’s conceptual integrity. The center must hold!

 It seems to be a popular pastime to condemn C++ for being a filthy mess caused by rampant design-by-committee. This has been suggested repeatedly since before the committee was founded, but I feel it is now far worse. Adding a lot of unrelated features and library components will do much to add complexity to the language, making it scarier to both novices and “mainline programmers”. What I do not want to try to do:
• Turn C++ into a radically different language
• Turn parts of  C++ into a much higher-level language by providing a segregated sub-language
• Have C++ compete with every other language by adding as many as possible of their features
• Incrementally modify C++ to support a whole new “paradigm”
• Hamper C++’s use for the most demanding systems programming tasks
• Increase the complexity of C++ use for the 99% for the benefit of the 1% (us and our best friends).

Like all the other C++ committee members, Bjarne is a really, really, smart guy. For the decades that I’ve followed his efforts to evolve and improve the language, Bjarne has always expressed empathy for “the little people“; the 99% (of which I am a card-carrying member).

In a world in which the top 1% doesn’t seem to give a shit about the remaining 99%, it’s always refreshing to encounter a 1 percenter who cares deeply about the other 99 percenters. And THAT, my dear reader, is what has always endeared Mr. Bjarne Stroustrup to me.

Ninety Nine Pct

I am often asked – often by influential and/or famous people – if I am planning a D&E2 (The Design And Evolution Of C++ version 2). I’m not, I’m too busy using and improving C++. However, should I ever find it convenient to semi-retire, D&E2 would be a great project. However, I could do that if and only if I could honestly write it without condemning the language or my friends. We need to ship something we can be proud of and that we can articulate.

W00t! I didn’t know I was influential and/or famous: And In The Beginning.

The Biggest Cheerleader

September 15, 2013 Leave a comment

Herb Sutter is by far the biggest cheerleader for the C++ programming language – even more so than the language’s soft spoken creator, Bjarne Stroustrup. Herb speaks with such enthusiasm and optimism that it’s infectious.

Herb Cheer

In his talk at the recently concluded GoingNative2013 C++ conference, Herb presented this slide to convey the structure of the ISO C++ Working Group 21 (WG21):

wg21 old org

On the left, we have the language core and language evolution working groups. On the right, we have the standard library working group.

But wait! That was the organizational structure as of 18 months ago. As of now, we have this decomposition:

WG21 new org

As you can see, there’s a lot of volunteer effort being applied to the evolution of the language – especially in the domain of libraries. In fact, most of the core language features on the left side exist to support the development of the upcoming libraries on the right.

In addition to the forthcoming minor 2014 release of C++, which adds a handful of new features and fixes some bugs/omissions from C++11, the next major release is slated for 2017. Of course, we won’t get all of the features and libraries enumerated on the slide, but the future looks bright for C++.

The biggest challenge for Herb et al will be to ensure the conceptual integrity of the language as a whole remains intact in spite of the ambitious growth plan. The faster the growth, the higher the chance of the wheels falling off the bus.

“The entire system also must have conceptual integrity, and that requires a system architect to design it all, from the top down.” – Fred Brooks

“Who advocates … for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks

I’m not a fan of committees in general, but in this specific case I’m confident that Herb, Bjarne, and their fellow WG21 friends can pull it off. I think they did a great job on C++11 and I think they’ll perform just as admirably in hatching future C++ releases.

The Gall Of That Man!

March 2, 2013 5 comments

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall (1975, p.71)

This law is essentially an argument in favour of underspecification: it can be used to explain the success of systems like the World Wide Web and Blogosphere, which grew from simple to complex systems incrementally, and the failure of systems like CORBA, which began with complex specifications.  – Wikipedia

We can add the Strategic Defense Initiative (Star Wars), the FBI’s Virtual Case File System (VCS) JTRS, FCS, and prolly a boatload of other high falutin’ defense projects to the list of wreckage triggered by violations of Gall’s law. Do you have any other majestic violations you’d like to share? Can you cite any counter-examples that attempt to refute the law….

One of the great tragedies of life is the murder of a beautiful theory by a gang of brutal facts – Benjamin Franklin

C++, which started out simply as “C With Classes“, is a successful complex “system“. Java, which started out as a simple and pure object-oriented system, has evolved into a successful complex system that now includes a mix of functional and generic programming features. Linux, which started out as a simple college operating system project, has evolved into a monstrously successful complex system. DDS, which started out as a convergence of two similar, field-tested, pub-sub messaging implementations from Thales Inc. and RTI Inc., has evolved into a successful complex system (in spite of being backed by the OMG). Do you have any other law abiding citizens you’d like to share?

Gall’s law sounds like a, or thee, platform for Fred Brooks“plan to throw one away” admonition and Grady Booch‘s “evolution through a series of stable intermediate forms” advice.

Here are two questions to ponder: Is your org in the process of trying to define/develop a grand system design from scratch? Scanning your project portfolio, can you definitively know if you’re about to, or currently are, attempting a frontal assault on Gall’s galling law – and would it matter if you did know?

Gall Gig

Messmatiques And Empathic Creators

February 29, 2012 Leave a comment

Assume that you have a wicked problem that needs fixing; a bonafide Ackoffian “mess” or Warfieldian “problematique” – a “messmatique“. Also assume (perhaps unrealistically) that a solution that is optimal in some sense is available:

The graphic below shows two different social structures for developing the solution; individual-based and group-based.

If the messmatique is small enough and well bounded, the individual-based “structure” can produce the ideal solution faster because intra-cranial communication occurs at the speed of thought and there is no need to get group members aligned and on the same page.

Group efforts to solve a messmatique often end up producing a half-assed, design-by-committee solution (at best) or an amplified messmatique (at worst). D’oh!

Alas, the individual, genius-based, problem solving structure is not scalable. At a certain level of complexity and size, a singular, intra-cranial created solution can produce the same bogus result as an unaligned group structure.

So, how to resolve the dilemma when a messmatique exceeds the capacity of an individual to cope with the beast? How about this hybrid individual+group structure:

Note: The Brooksian BD/UA is not a “facilitator” (catalyst) or a hot shot “manager” (decider). He/she is both of those and, most importantly, an empathic creator.

Composing a problem resolution social structure is necessary but not sufficient for “success“. A process for converging onto the solution is also required. So, with a hybrid individual+group social structure in place, what would the “ideal” solution development process look like? Is there one?

Invisible, Thus Irrelevant

October 19, 2011 Leave a comment

A system that has a sound architecture is one that has conceptual integrity, and as (Fred) Brooks firmly states, “conceptual integrity is the most important consideration in system design”. In some ways, the architecture of a system is largely irrelevant to its end users. However, having a clean internal structure is essential to constructing a system that is understandable, can be extended and reorganized, and is maintainable and testable.

The above paragraph was taken from Booch et al’s delightful “Object-Oriented Analysis And Design With Applications“. BD00’s version of the bolded sentence is:

In some ways, the architecture of a system is largely irrelevant to its end users, its developers, and all levels of management in the development organization.

If the architecture is invisible because of the lack of a lightweight, widely circulated, communicated, and understood, set of living artifacts, then it can’t be relevant to any type of stakeholder – even a developer. As the saying goes: “out of site, out of mind“.

Despite the long term business importance of understandability, extendability, reorganizability, maintainability, and testability, many revenue generating product architectures are indeed invisible – unlike short term schedulability and budgetability; which are always highly visible.

A Bunch Of STIFs

October 2, 2011 2 comments

In “Object-Oriented Analysis and Design with Applications“, Grady Booch argues that a successful software architecture is layered, object-oriented, and evolves over time as a series of STIFs – STable Intermediate Forms. The smart and well liked BD00 agrees; and he adds that unsuccessful architectures devolve over time as a series of unacknowledged UBOMs (pronounced as “You Bombs“).

UBOMs are subtle creatures that, without caring stewardship, can unknowingly sneak up on you. Your first release or two may start out as a successful STIF or a small and unobtrusive UBOM. But then, since you’ve stepped into UBOM-land, it can grow into an unusable, resource-sucking abomination. Be careful, very careful….

“Who advocates for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks

“Dear Fred, when the primary thought held steadfast in everybody’s mind is “schedule is king” instead of “product is king“, of course no one will often advocate for the product.” – BD00

%d bloggers like this: