Archive
Requisite Knowledge
In “Item 3. Design Patterns” of Stephen Dewhurst’s “C++ Common Knowledge: Essential Intermediate Programming“, he states the following:
Design patterns are often described as “micro-architectures” that can be composed with other patterns to produce a new architecture. Of course, selecting appropriate patterns and composing them effectively requires design expertise and native ability. However, even your manager will be able to understand the completed design if he or she has the requisite knowledge of patterns.
Uh, Stephen, you’re kidding, ain’t ya? In a project mini-corpricracy like the one below, you’ll be lucky if even the software lead knows what a pattern is, let alone the lofty manager. The software “Rocket-tect” will most likely know what a pattern is – but probably not how to apply it since he/she will be stuck in “lemme-show-u-how-smart-I-am” jargon-land. On the bright side, everybody in the power structure (which excludes the programmers, of course) will know what a Microsoft schedule, spreadsheet, and powerpoint deck are.
How’s Your GoF Swing?
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”.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 