Posts Tagged ‘Grady Booch’

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

Illusion, Not Amplification

September 23, 2011 Leave a comment

The job of the product development team is to engineer the illusion of simplicity, not to amplify the perception of complexity.

Software guru Grady Booch said the first part of this quote, but BD00 added the tail end. Apple Inc.’s product development org is the best example I can think of for the Booch part of the quote, and the zillions of mediocre orgs “out there” are a testament to the BD00 part.

According to Warren Buffet, the situation is even worse:

There seems to be some perverse human characteristic that likes to make easy things difficult. – Warren Buffet

Translated to BD00-lingo:

Engineers like to make make easy things difficult, and difficult things incomprehensible.

Why do they do it? Because:

A lot of people mistake unnecessary complexity for sophistication. – Dan Ward


The quickest routes to financial ruin are: wine, women, gambling….. and engineers

Ubiquitous Dishonorability

September 21, 2011 2 comments

While reading the delightful “Object-Oriented Analysis and Design with Applications“, Grady Booch et al extol the virtues of object-oriented analysis over the venerable, but passe, structured analysis approach to front end system composition. As they assert below, one of the benefits of OOA is that it’s easier and more natural to avoid mixing concrete design details with abstract analysis results.

Out of curiosity (which killed the cat), I scrolled down to see what note [4] meant:

WTF? Do they mean “because that’s the way the boss sez it must be done!” and “because that’s the way we’ve always done it!” aren’t honorable reasons for maintaining the status quo? If so, then dishonorable behavior runs rampant within the halls of most software shops the world over. But you already knew that, no?

An Answer 10 Years Later

March 14, 2011 Leave a comment

I’ve always questioned why one of my mentors from afar, Steve Mellor, was one of the original signatories of the “Agile Manifesto” 10 years ago. He’s always been a “model-based” guy and his fellow pioneer agile dudes were obsessed with the idea that source code was the only truth – to hell with bogus models and camouflage documents. Even Grady Booch, another guy I admire, tempered the agilist obsession with code by stating something like this: “the code is the truth, but not the whole truth“.

Stephen recently sated my 10 year old curiosity in this InfoQ interview: “A Personal Reflection on Agile Ten Years On“. Here’s Steve’s answer to the question that haunted me fer 10 ears:

The other signatories were kind enough, back in 2001, to write the manifesto using the word “software” (which can include executable models), not “code” (which is more specific.) As such I felt able, in good conscience, to become a signatory to the Manifesto while continuing to promote executable modeling. Ten years on we have a standard action language for agile modeling. – Stephen J. Mellor

The reason I have great respect for Stephen (and his cohort Paul Ward) is this brilliant trilogy they wrote waaaayy back in the mid 80s:

Despite the dorky book covers and the dates they were written, I think the info in these short tomes is timeless and still relevant to real-time systems builders today. Of course, they were created before the object-oriented and multi-core revolutions occurred, but these books, using simple DeMarco/Plauger structured analysis modeling notation (before UML), nail it. By “it”, I mean the thinking, tools, techniques, idioms, and heuristics required to specify, design, and build concurrent, distributed, real-time systems that work. Buy em, read em, decide for yourself, bookmark this post, and please report your thoughts back to me.

The Sociopaths, The Clueless, And The Losers

November 9, 2010 Leave a comment

So, you’ve never heard of the “gaping void”? Hugh MacLeod? “Ignore Everybody“? Here’s a taste of Hugh’s work:

Of course, I fall into Hugh’s “Losers” category, but considering the alternatives I feel pretty good.

For you fellow software weenies, here’s what Grady Booch (in Masterminds Of Programming) has to say:

There’s a delightful site called Gaping Void. He’s basically a PR-type person and his claim to fame is he does art on the back of business cards. But he has this riff which has been very popular about how to be creative. You might point your readers to that one.

Uh, what are you waiting for? Scurry on over to Hugh’s site and sign up for his daily cartoon. You won’t be disappointed and you’ll feed your famished mind with some tasty food. Yum yum!

How’s Your GoF Swing?

October 12, 2010 4 comments

I don’t think many software professionals would disagree with the assertion that one of the greatest and innovative software design books of all time is “Design Patterns” by the Gang of Four (GoF). According to these PGA GoFfers, one dimensional software developers who only cut code and are “above” documenting behavioral and structural views of their designs do everyone a great disservice, especially themselves.  Here’s why:

An object-oriented program’s run-time structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program’s run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa. With such disparity between a program’s run-time and compile-time structures, it’s clear that code won’t reveal everything about how a system will work. – Design Patterns, GoF.

Here’s the double whammy from UML co-creator Grady Booch.

The (source) code is the truth, but not the whole truth. – Grady Booch

I interpret these quotes to mean that without supporting “artifacts” (I use the less offensive “a” word here because “documentation” to most programmers is the equivalent of a four letter word.) to aid in understanding, maintenance developers and new team members and even the original coders are hosed. Of course, it goes without saying that their organizations and customers are hosed too. The hosing may be later than sooner, but the hosing will take place.

“The bitterness of poor system performance remains long after the sweetness of low prices and prompt delivery are forgotten.” – Jerry Lim

When one dimensional programmers are combined with one dimensional, schedule-is-the-only-thing-that-matters BMs who don’t care to know squat about software other than that the code is “done”, a toxic and self-reinforcing 2 X 1D brew of inefficiency and endless downstream rework is guaranteed. No superficial org restructurings, process improvement initiatives, excellence committees, or executive orders can solve deeply rooted quality problems like this. Bummer.

So what’s the advice that goes with this typical Bulldozer00 rant? Learn UML (on your own time; see the quote below) and develop your software from end-to-end with a process that interlaces coding and “artifacting” similar to PAYGO.

“I hold great hopes for UML, which seems to offer a way to build products that integrates hardware and software, and that is an intrinsic part of development from design to implementation. But UML will fail if management won’t pay for quite extensive training, or toss the approach when panic reigns.” – Jack Gannsle

My version of Jack’s quote replaces the “if” with “when”.

A Pencast

September 7, 2010 Leave a comment

Checkout mypencastof the legendary Grady Booch talking about software architecture. In this notes+audio mashup, Grady expounds on the importance of patterns within elegant and robust architectures. Don’t mind my wife and dog’s barking, uh, I mean my dog’s barking and my wife’s talking, in a small segment of the pencast.

Go, Go Go!

August 6, 2010 Leave a comment

Rob Pike is the Google dude who created the Go programming language and he seems to be on a PR blitz to promote his new language. In this interview, “Does the world need another programming language?”, Mr. Pike says:

…the languages in common use today don’t seem to be answering the questions that people want answered. There are niches for new languages in areas that are not well-served by Java, C, C++, JavaScript, or even Python. – Rob Pike

In Making It Big in Software, UML co-creator Grady Booch seems to disagree with Rob:

It’s much easier to predict the past than it is the future. If we look over the history of software engineering, it has been one of growing levels of abstraction—and, thus, it’s reasonable to presume that the future will entail rising levels of abstraction as well. We already see this with the advent of domain-specific frameworks and patterns. As for languages, I don’t see any new, interesting languages on the horizon that will achieve the penetration that any one of many contemporary languages has. I held high hopes for aspect-oriented programming, but that domain seems to have reached a plateau. There is tremendous need to for better languages to support massive concurrency, but therein I don’t see any new, potentially dominant languages forthcoming. Rather, the action seems to be in the area of patterns (which raise the level of abstraction). – Grady Booch

I agree with Grady because abstraction is the best tool available to the human mind for managing the explosive growth in complexity that is occurring as we speak. What do you think?

Abstraction is selective ignorance – Andrew Koenig

Black And White Binary Worlds

November 17, 2009 1 comment

In this interview with the legendary Grady Booch, (InformIT: Grady Booch on Design Patterns, OOP, and Coffee), Larry O’Brien had this exchange with one of the original pioneers of object oriented design and the UML:

Larry: Joel Spolsky said:

“Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture.”

He also said:

“Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on…And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about,….and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.”

Spolsky seems to represent a real constituency that is not just dismissive but outright hostile to software development approaches that are not code-centric. What do you say to people who are skeptical about the value of work products that don’t compile?

Grady: You may be surprised to hear that I’m firmly in Joel’s camp. The most important artifact any development team produces is raw, running, naked code. Everything else is secondary or tertiary. However, that is not to say that these other things are inconsequential. Rather, our models, our processes, our design patterns help one to build the right thing at the right time for the right stakeholders.

I think that Grady’s spot on in that both the code-centric camp and the architecture-centric camp tend to throw out what’s good from the other camp. It’s classic binary extremism where things are either black or white to the participants and the color grey doesn’t exist in their minds. Once a rigid and unwavering mindset is firmly established, the blinders are put on and all learning stops. I try to keep this in mind all the time, but the formation of a black/white mindset is hard to detect. It creeps up on you.

Black And White

%d bloggers like this: