Archive
PPPP Invention
In “Engineering A Safer World“, Nancy Leveson uses the autopilot example below to illustrate the extra step of complexity that was introduced into the product development process with the integration of computers and software into electro-mechanical system designs.
In the worst case, as illustrated below, the inter-role communication problem can be exacerbated. Although the “gap of misunderstanding” from language mismatch is always greatest between the Domain Expert and the Software Architect, as more roles get added to the project, more errors/defects are injected into the process.
But wait! It can get worse, or should I say, “more challenging“. Each person in the chain of cacophony can be a member of a potentially different group with conflicting goals.
But wait, it can get worser! By consciously or unconsciously adding multiple managers and executives to the mix, you can put the finishing touch on your very own Proprietary Poop Producing Process (PPPP).
So, how can you try to inhibit inventing your very own PPPP? Two techniques come to mind:
- Frequent, sustained, proactive, inter-language education (to close the gaps of misunderstanding).
- Minimization of the number of meddling managers (and especially, pseudo-manager wannabes) allowed anywhere near the project.
Got any other ideas?
Software Development Cost Saving Tip
It’s easier (read as lower cost) to retest existing code with an “updated” requirement that was wrong or impossible to satisfy than it is to change and retest code in order to match an “unquestioned” requirement.
An Epoch Mistake
Let’s start this hypothetical story off with some framing assumptions:
Assume (for a mysterious historical reason nobody knows or cares to explore) that timestamps in a legacy system are always measured in “seconds relative to midnight” instead of “seconds relative to the unix epoch of 1/1/1970“.
Assume that the system computes many time differences at a six figure Hz rate during operation to fulfill it’s mission. Because “seconds relative to midnight” rolls over from 86399 to 0 every 24 hours, the time difference logic has to detect (via a disruptive “if” statement) and compensate for this rollover; lest its output is logically “wrong” once a day.
Assume that the “seconds relative to the unix epoch of 1/1/1970” library (e.g. Boost.Date_Time) satisfies the system’s dynamic range and precision requirements.
Assume that the design of a next generation system is underway and all the time fields in the messages exchanged between the system components are still mysteriously specified as “seconds since midnight” – even though it’s known that the added CPU cycles and annoyance of rollover checking could be avoided with a stroke of the pen.
Assume that the component developers, knowing that they can dispense with the silly rollover checking:
- convert each incoming time field into “seconds since the unix epoch“,
- use the converted values to perform their internal time difference computations without having to check/compensate for midnight rollover,
- convert back to “seconds since midnight” on output as required.
Assume that you know what the next two logical steps are: 1) change the specification of all the time fields in the messages exchanged between the system components from the midnight reference origin to the unix epoch origin, 2) remove the unessential input/output conversions:
Suffice it to say, in orgs where the culture forbids the admittance of mistakes (which implicates most orgs?) because the mistake-maker(s) may “look fallible“, next steps like this are rarely taken. That’s one of the reasons why old product warts are propagated forward and new warts are allowed to sprout up in next generation products.
Scrumming For Dollars
“Systems Engineering with SysML/UML” author Tim Weilkiens recently tweeted:
Tim’s right. Check it out yourself: Scrum Guide – 2011.
Before Tim’s tweet, I didn’t know that “software” wasn’t mentioned in the guide. Initially, I was surprised, but upon further reflection, the tactic makes sense. Scrum creators Ken Schwaber and Jeff Sutherland intentionally left it out because they want to maximize the market for their consulting and training services. Good for them.
As a byproduct of synthesizing this post, I hacked together a UML class diagram of the Scrum system and I wanted to share it. Whatcha think? A useful model? Errors, omissions? Does it look like Scrum can be applied to the development of non-software products?
Product Lifetime
The UML state transition diagram below depicts the growth, maturity, and retirement of a large, software-intensive product. There are a bazillion known and unknown factors that influence the longevity and profitability of a system, but the greatest determinant is how effectively the work in the upfront “Develop” state is executed.
If the “Develop” state is executed poorly (underfunded, undermanned, mis-manned, rushed, “pens down“, etc), then you better hope you’ve got the customer by the balls. If not, you’re gonna spend most of your time transitioning into, and dwelling within, the resource-sucking “Fix” state. If you do have cajones in hand, then you can make the customer(s) pay for the fixes. If you don’t, then you’re hosed. (I hate when that happens.)
If you’ve done a great job in the “Develop” state, then you’re gonna spend most of your time transitioning into and out of the “Enhance” state – keeping your customer delighted and enjoying a steady stream of legitimate revenue. (I love when that happens.)
The challenge is: While you’re in the “Develop” state, how the freak do you know you’re doing a great job of forging a joyous and profitable future? Does being “on schedule” and “under budget” tell you this? Do “checked off requirements/design/code/test reviews” tell you this? Does tracking “earned value” metrics tell you this? What does tell you this? Is it quantifiably measurable?
Apple-less
Amazingly, I’ve never owned an Apple product. Despite this fact, I admire Apple and the culture that Steve Jobs brutally, but single-handedly, instilled into the company. These excerpts from “Jobs questioned authority all his life” explain why:
Jobs called the crop of executives brought in to run Apple after his ouster in 1985 “corrupt people” with “corrupt values” who cared only about making money. Jobs himself is described as caring far more about product than profit.
He told (biographer) Isaacson they cared only about making money “for themselves mainly, and also for Apple — rather than making great products.”
Despite Apple’s unprecedented success behind Jobs’ “products, strategy, people” credo, most captains of industry and their mini-me clones just don’t get it – and it looks like they never will. I think capitalism is the least inequitable “ism” there is, but extreme capitalism is no better than any other “ism“.
Ironic
It’s like ten thousand spoons when all you need is a knife – Alanis Morissette
I find it curiously ironic that despite what may be espoused, software developers are often placed on one of the lowest rungs of the ladder of stature and importance (but alas, the poor test engineers often rank lowest) in many corpricracies whose revenue is dominated by software-centric products. Yet, it seems that many front-line software project managers, software “leads“, and software “rocketects” are terrified of joining the fray by designing and writing a little code here and there to lead by example and occasionally help out. In mediocre corpo cultures, it’s considered a step “backward” for titled ones to cut some code.
Fuggedaboud writing some code, a lot of the self-pseudo-elite dudes are afraid of even reading code for quality. Hence, to justify their existence, they focus on being meticulous process, schedule, and status-taking wonks – which of course unquestioningly requires greater skill, talent, and dedicated effort than designing/coding/testing/integrating revenue generating code.
Sustained Viability
The figure below shows the sales-vs-time trend chart of a one hit wonder company. The sales from product “A” ramp up, settle out, and then ramp down.
The ramp up, steady-state, and ramp down time intervals in which sales > $0 varies wildly from one company to another and depends on many factors: how easy the product is to copy, whether the product is obsoleted by another product, how big the market is, whether or not the product keeps evolving to meet new customer demands; yada, yada, yada.
To maintain sustained viability and to avoid being a one hit wonder company, new products must be continuously developed to offset the eventual decline in sales from the aging one hitter. The longer the “flat” segment of sustained sales is, the easier it is to become fat/happy/complacent and stop creating and innovating.
The figure below traces the rise and fall of a three hit company. The green vertical lines are snapshots of the company’s sales at four different points in time.
At the peak of success, all three products have leveled off at their maximum sales levels and the good times are a rollin’. Then, for an unknown reason(s), the product pipeline is suddenly empty, and one by one, sales start decreasing for each product.
So what’s the point of this inane post? Hell, I don’t freakin’ know. I was just doodlin’ around with visio, sketchin’ away, makin’ stuff up, and these graphs emerged from the wild blue yonder. Sorry for wastin’ your time. It wasn’t a waste of mine.
Asynchronous Evolution
In “Engineering A Safer World“, Nancy Leveson asserts that “asynchronous evolution” is a major contributor to costly accidents in socio-technical systems. Asynchronous evolution occurs when one or more parts in a system evolve faster than other parts – causing internal functional and interface mismatches between the parts. As an example, in a friendly fire accident where a pair of F-15 fighters shot down a pair of black hawk helicopters, the copter and fighter pilots didn’t communicate by voice because they had different radio technologies on board.
As another example, consider the graphic below. It shows a project team comprised of domain analysts and software developers along with two possible paths of evolution.
Happenstance asynchronous evolution is corrosive to product excellence and org productivity. It underpins much misunderstanding, ambiguity, error, and needless rework. Org controllers that diligently ensure synchronous evolution of the tools/techniques/processes amongst the disciplines that create and build its revenue generating products own a competitive advantage over those that don’t, no?
Dysfunctional Interactions
In “Engineering A Safer World“, Nancy Leveson states that dysfunctional interactions between system parts play a bigger role in accidents than individual part failures. Relative to yesterday’s systems, today’s systems contain many more parts. But because of manufacturing advances, each part is much more reliable than it used to be.
A consequence of adding more parts to a system is that the numbers of potential connections and interactions between parts starts exploding fast. Hence, there’s a greater chance of one dysfunctional interaction crashing the whole system – even whilst the individual parts and communication links continue to operate reliably.
Even with a “simple” two part system, if its designed-in purpose requires many rich and interdependent interactions to be performed over the single interface, watch out. A single dysfunctional interaction can cause the system to seize up and stop producing the emergent behavior it was designed to provide:
So, what’s the lesson here for system designers? It’s two-fold. Minimize the number of interfaces in your design and, more importantly, limit the number, types, and exchanges over each interface to only those that are required to fulfill the system’s purpose. Of course, if no one knows what’s required (which is the number one cause of unsuccessful systems), then you’re hosed no matter what. D’oh!
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 