When creating an architecture or detailed design of a system component, up to three forms of design evaluation can be performed:
- A: Continuous evaluation by the designer during the process
- B: Evaluation by a peer group at one or more review events during the process
- C: Evaluation by an expert outsider group after A and B
These three forms of evaluation are illustrated in the sequence of diagrams below. Note that as each evaluation type is progressively added to the mix, a new feedback loop is introduced into the system.
During A, the conceive/evaluate/repair loop is performed at the speed of thought within the isolated mind of the designer. As the designer applies his skills to his understanding of the problem to be solved, alternative component structures and configurations can pop up instantaneously during each of many high frequency loop traversals. At some point, the designer concludes that his design solution is stable enough for external scrutiny and/or ready for the next step of realization.
During B, the designer walks through his creation in front of a group of peers. He explains the structure and behavior mechanisms of his design and how it solves the problem. If the peer group is qualified, prepared, and objective (QPO), at least a portion of the feedback the group produces will be valuable to the designer and he will use it to improve his design. However, unless all three QPO pre-conditions are satisfied, the peer review process will be a huge waste of time and money.
Jetting in an expert outsider group is the riskiest type of evaluation. Assuming that the QPO criteria is satisfied, the fact that the expert outsider group has no real “skin in the game” after it vacates the premises should be a cause for concern to anyone contemplating the use of the technique.
In general, the more negative feedback loops incorporated into a process, the more likely the process is to produce its intended output. As the final figure above implies, incorporating all three types of evaluation into a design review process can lead to a high quality design. However, blindly ignoring the QPO criteria and/or failing to address the “skin in the game” risk can increase cost, lengthen schedule, and lay waste to your well-intentioned review process – without you ever knowing that it occurred. As ever, the devil is in the details.
Either directly or subliminally, the message I hear from hardcore agilista big-wigs is that an agile process trumps a traditional plan-driven software development process every time and in every context – no exceptions.
On the other hand, the message I hear from traditionalists is… well, uh, I don’t hear much from traditionalists anymore because they’ve been beaten into silence by the hordes of unthinking zombies unleashed upon them by the agilista overlords.
Regarding the “betterness” of #agile over #traditional (or #noestimates over #estimates, or #noprojects over #projects), please leave your handful of personal anecdotes at home. Charismatic “I’ve seen” and “in my (vast) experience” stories don’t comprise science and aren’t sufficient justifications for sweeping generalizations. The science simply doesn’t exist – especially for the construction of large, distributed software systems.
I suppose that if a plausible (and thus, falsifiable) theory of software development processes was to be methodically derived from first principles and rigorously tested via a series of repeatable experiments, the general result would end up looking something like this:
What predictive capabilities do you think a credible theory of software development processes would generate? Show Me Your Curves.
I keep finding myself being drawn more and more into circular Twitter debates with self-proclaimed software development gurus, many of whom who write books and give speeches for a living. On the upside, I’m thrilled that Twitter gives me the opportunity to interact in near-real-time with people I never thought I’d have the chance to otherwise communicate with. On the downside, I do not enjoy the increasing amounts of time and energy it takes to steer these oft head-banging conversations toward a graceful closure where neither side feels dissed.
The topic of software development is simply too context-dependent to arrive at a sweeping consensus on almost anything of non-trivial importance. Trying to get someone who develops software in the context of the aerospace & defense industry to fully agree with someone who develops IT web sites or mobile game apps for a living is like trying to get republicans and democrats to agree on… anything.
But alas, I’m such a sucker for instigating and perpetuating incendiary, no-win, arguments. Like this famously hilarious scene in OFOTCN between Taber and Harding, I’m genetically inclined to frequently behave online (and offline) as an obnoxious “poker“:
If you’re a natural born “poker“, deploy your poking skills at work only on peers. My experience has been that the practice of “poking” management, at any level in the hierarchy, never works – ever. It doesn’t matter what your message is. The fact that you’re delivering it with the tip of your poker is the only thing that matters. So, when it comes to management, keep your poker in your pants.
Here’s your miserable predicament:
Here’s what Scrum can give you:
All ya gotta do to transform your 20th century horse and buggy into a 21st century Ferrari is hire a gaggle of agile coaches, agile scalers, and agile adoption experts to facilitate the much-heralded transformation:
So, what’s in da magic box? Shhhhhhh! BD00 knows. That scoundrel signed an NDA and successfully bribed some well-known, high profile, agile transformers into disclosing their 5 process secrets. Four of them consist of the following parallel micro-transformations:
The fifth transformation process component is the most important and well-guarded secret of the lot. BD00 had to pay an extra premium before it was disclosed. It is hoodwinking the eager sponsor into believing that the transformation was an astounding success:
After all was said and done, more was said than done.
Assume that your team was tasked with developing a large software system in any application domain of your choice. Also, assume that in order to manage the functional complexity of the system, your team iteratively applied the “separation of concerns” heuristic during the design process and settled on a cleanly layered system as such:
So, how are you gonna manifest your elegant paper design as a working system running on real, tangible hardware? Should you build it from the bottom up like you make a cake, one layer at a time?
Or, should you build it like you eat a cake, one slice at a time?
The problem with growing the system layer-by-layer is that you can end up developing functionality in a lower layer that may not ever be needed in the higher layers (an error of commission). You may also miss coding up some lower layer functionality that is indeed required by higher layers because you didn’t know it was needed during the upfront design phase (an error of omission). By employing the incremental slice-by-slice method, you’ll mitigate these commission/omission errors and you’ll have a partially working system at the end of each development step – instead of waiting until layers 1 and 2 are solid enough to start adding layer 3 domain functionality into the mix.
In the context of organizational growth, Russell Ackoff once stated something like: “it is better to grow horizontally than vertically“. Applying Russ’s wisdom to the growth of a large software system:
It’s better to grow a software system horizontally, one slice at a time, than vertically, one layer at a time.
The above quote is not some profound, original, BD00 quote. It’s been stated over and over again by multitudes of smart people over the years. BD00 just put his own spin on it.
It took me approximately 20 minutes of iterative e-sketching to whip up the following figure:
During the process of construction, I experienced a slew of fragmented, half-baked, thoughts on how to present the intent and meaning of the diagram with some accompanying text. After I deemed the diagram “done“, I uploaded it to this page and reflected on it for 10 more minutes – trying to stitch the thought fragments together into some kind of coherent story that would interest you. I know the overarching theme has something to do with “matched system design“, but that’s all. I failed; and it’s time to move on.
If you’re a C++ programmer, you’ve surely written code in accordance with the RAII (Resource Acquisition Is Initialization) idiom. Inspired by the RAII acronym, BD00 presents the RAID idiom: Requirements Allocation Is Design…
In order to allocate requirements to a design, you must have a design in mind that you think satisfies those requirements. Circularly speaking, in order to create a design (like the one above), you must have a set of requirements in mind to fuel your design process. Thus, RAID == DIRA (Design Is Requirements Allocation).