The Big Rebuttal
I’ve heard lots of political speech rebuttals, blog post rebuttals, book review rebuttals, interview rebuttals, and editorial rebuttals, but I can’t remember the last time I stumbled upon a full blown book rebuttal – until recently.
About a year ago, I read Michael Lewis’s “Flash Boys: A Wall Street Revolt“. Mr. Lewis, a former Salomon Brothers bond trader, is a major league author who has penned a gaggle of incendiary best-sellers such as “Liar’s Poker”, “The Money Culture”, “Moneyball”, and “The Big Short”. Coupled with my utter disdain of Wall Street’s “risk management” practices and its apathetic “let them eat cake” attitude toward Main Street, I seem to always end up wanting to take up arms and go “occupy Wall St.” after reading one of Mr. Lewis’s books. But of course, I never do.
“Flash Boys” so enraged former high-frequency trader Peter Kovac that he felt compelled to write a full blown, point for point, rebuttal book titled “Flash Boys: Not So Fast“.
Out of curiosity, I downloaded and read the free kindle sample of “Not So Fast“. Although Mr. Kovac makes a very valid point in that Mr. Lewis never spoke to any inside high frequency traders during the research phase of “Flash Boys“, I declined to buy and read the full book. I didn’t buy it because, just as Mr. Lewis (and BD00) is biased against Wall St. psychopathy, Mr. Kovac is biased for Wall St. and our so-called free markets (which are really hostage markets rigged for the rich and powerful to leave Main St. in the dust).
Every person, with very, very, very, few exceptions (the Buddha, Jesus, Echart Tolle, J. Krishnamurti, Sri Ramana Maharshi?), feels strongly about certain man-made values and principles. Since I’m not one of those exceptions, I say “Nice Try!” to Peter Kovac. Thanks, but no thnks.
NFRs And QARs
At the first level of decomposition, a software requirement can be classified as either “functional” or “non-functional“. A functional requirement (FR) specifies a value-added behavior/capability/property that the software system must exhibit during runtime in order for it to be deemed acceptable by its customers and users. A non-functional requirement (NFR) specifies how well one or more behaviors/capabilities/properties must perform.
Unlike FRs, which are nominally local, fine-grained, and verifiable early in the project, NFRs are typically global, coarse-grained, and unverifiable until a considerable portion of the system has been developed. Also, unlike FRs, NFRs often have cold, hard-to-meet, numbers associated with them:
- The system shall provide a response to any user request under a full peak load of 1000 requests per second within 100 milliseconds. (throughput, latency NFRs)
- The system shall be available for use 99.9999 percent of the time. (availability NFR)
- The system shall transition from the not-ready to ready within 5 seconds. (Domain-specific Performance NFR)
- The system shall be repairable by a trained technician within 10 minutes of the detection and localization of a critical fault. (Maintainability NFR)
- The system shall be capable of simultaneously tracking 1000 targets in a clutter-dominated environment. (Domain-specific Performance NFR)
- The system shall detect an air-breathing target with radar cross-section of 1 sq. meter at a range of 200 miles with a probability of 90 percent. (Domain-specific Performance NFR)
- The system shall produce range estimates within 5 meters of the true target position. (Domain-specific Performance NFR)
- The system shall provide TCP/IP, HTTP, CORBA, and DDS protocol support for interfacing with external systems. (Interoperability NFR)
During front-end system conception, NFRs are notoriously underspecified – if they’re formally specified at all. And yet, unlike many functional requirements, the failure to satisfy a single NFR can torpedo the whole effort and cause much downstream, career-ending, mischief after a considerable investment has been sunk into the development effort.
Since extra cross-cutting functionality (and extra hardware) must often be integrated into a system architecture (from the start) to satisfy one or more explicit/implicit NFRs, the term “non-functional requirement” is often a misnomer. Thus, as the SEI folks have stated, “Quality Attribute Requirement” (QAR) is a much more fitting term to specify the “how-well-a-system-must-perform” traits:
As the figure below illustrates, the “QARization” of a system can substantially increase its design and development costs. In addition, since the value added from weaving in any extra QAR software and hardware is mostly hidden under the covers to users and only becomes visible when the system gets stressed during operation, QARs are often (purposely?) neglected by financial sponsors, customers, users, AND developers. Stakeholders typically want the benefits without having to formally specify the details or having to pay the development and testing costs.
It’s sad, but like Rodney Dangerfield, QARs get no respect.
Cheers Charlie!
Charlie Alfred is a highly intelligent and eloquent writer on the topic of software architecture. He is the first (and still, only) internet friend that I’ve met in real life; face-to-face. We hooked up for lunch to shoot the shit twice when he was visiting a client of his located in my neighborhood.
Charlie is the second person to affirm my deeply held belief that “context is king” in software architecture. He also taught me about the concept of “the architecture of the problem“. But like all good relationships, ours isn’t all about mushy love, kisses, and total agreement. Charlie often provides valuable counter-intelligence to my blustery blogging BS that causes me to step back, reconsider, and often soften my beliefs.
Since my friend Charlie hasn’t been feeling well lately and I haven’t interacted with him in a while, I’d like to wish Charlie and his family a very special, very merry, Christmas.
A heartfelt thanks to Ruth Malan for suggesting the idea of this post.
Inside-Out, Outside-In
There are two common perspectives on the process of architectural design, whether it be for buildings or for software. The first is that a designer starts with nothing—a blank slate, whiteboard, or drawing board—and builds-up an architecture from familiar components until it satisfies the needs of the intended system. The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system. Where the first emphasizes creativity and unbounded vision, the second emphasizes restraint and understanding of the system context. – “RESTful” Roy Fielding
It might not be a correct interpretation, but BD00 associates Mr. Fielding’s two alternatives with “inside-out” and “outside-in” design.
The figure below illustrates the process of inside-out design. The designer iteratively composes a structure and “hopes” it will integrate smoothly downstream into the context for which it is intended. During the inside-out design process, the parts are king and the system context is secondary.
The figure below depicts an outside-in design process. The designer iteratively composes a structure within the bounded constraints of the context (the “whole“) for which it is intended. During the outside-in design process, system context is king and the parts are secondary.
Because system contexts can vary widely from system to system and they’re usually vaguely defined, messy, and underspecified, designers often opt for the faster inside-out approach. BD00 uses the outside-in design process. What process do you use?
The Feat On Foot
Looky at what I got:
It took me a little over 2 years to perform this tremendous feat on foot.
With the circumference of the earth taping in at 24,901 miles, it will take approximately 14 more years for me to hike around the world. I’m considering changing my handle to ForrestChump00.
Three Forms Of Evaluation
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.
Show Me Your Curves
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.
Just Touch Me Once More!!!
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.
The Five Secrets
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.
Slice By Slice Over Layer By Layer
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.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 