Abstract Decomposition And Concrete Composition
On the left we have the process of abstract decomposition, and on the right we have the process of concrete composition:
Note that during the concrete composition from parts to final system on the right, we gracefully transition through two stable, intermediate forms. Some people and communities, especially those obsessed with “velocity” and “time-to-market“, would say “bollocks” to all those value-subtracting, intermediate steps. We no need no stinking intermediate forms:
The Trees And The Forest
As a result of an online Twitter exchange with Mr. Jon Quigley, I was able to purchase a copy of his and Kim Pries’s book, “Project Management Of Complex And Embedded Systems“. In exchange for a half-price deal, I promised to blog a review of the book and, thus, this is it.
As indicated by the book title, the subject matter is all about the methods and tools commonly used by program/project managers for orchestrating large, capital-intensive, multi-disciplined, product development endeavors. Specifically, the content focuses on how the automotive industry successfully manages the development and production of products composed of thousands of electro-mechanical parts and hundreds of networked processors, some of which run safety-critical software. Even though we tend to take them for granted, when you think about it, an automobile is an extremely complex distributed system requiring lots of coordinated mental, physical, and automated, labor to produce.
The book provides comprehensive, yet introductory, coverage of the myriad of tools and processes used in the world of big project management. It’s more of a broad, sweeping, reference book than a detailed step-by-step prescription for executing a specific set of processes. It’s jam packed with lots of useful lists, figures, tables, and graphs. The end of each chapter even includes a specific “war story” experienced by one or both of the authors over their long careers.
As a long time software developer of complex embedded systems in the aerospace and defense industry, much of the book’s subject matter is familiar to me. RFPs, SOWs, WBSs, EVM, BOMs, V&V, SRRs, PDRs, CDRs, TRRs, FMEA, staged-gate phases, prime-subcontractor relationships, master schedules, multi-level approvals, quality metrics, docu-centric information exchanges, etc, are amongst the methods used to facilitate, focus, constrain, and guide end-to-end system development. Many of the chapter-ending war stories tickled my funny bone too!
For the types of projects Mssrs. Pries and Quigley target in the book, kicking off a project at sprint 0 with a self-organizing team of eight cross-functional developers and a primed product backlog of user stories just doesn’t cut it. So, if you’re a young, naive, cloistered software developer or scrum master or product owner who belittles all “traditional“, rigorous, non-agile processes, I highly recommend this book. It will give you a glimpse into a whole different world and broaden your horizons – perhaps allowing you to see both the trees and the forest.
Breakthrough
A long time friend of BD00’s, Mr. William L. Livingston IV, asked me to post the following provocative product sheet on this blog:
Breakthrough October 2014
Everyone knows breakthroughs come in various kinds and sizes. The breakthrough announced here is in social system productivity. The noteworthy dimension of this breakthrough is the huge size of its available collective impact.
The math of its extravagant benefit is simple. This breakthrough applies to the productivity of any social system producing goods or services. The typical boost in social system productivity in application experience is 20%. The 2014 productivity of all the social systems around the globe, measured by the value of goods and services produced, the World Gross National Product, is $40 Trillion. By multiplication, the economic value of the benefit of this breakthrough to the world GNP is $8 Trillion/annum.
- The cost of the program is trivial. Its ROI computes in the many hundreds.
- No changes in facilities or personnel is necessary. Nothing is required of management.
- The attained positive transformation is fast. Program success is established and obvious in a couple of days. Tangible, measurable benefits start appearing in a couple of weeks.
- The program is transparent, natural law based, incontrovertible. Nothing is hidden. It has the characteristics necessary for universal, unconditional application.
- The need for this program cannot diminish. Its market opportunity is continuously replenished by business as usual.
- While the benefits to the participants sustain indefinitely after the program ends, eventually, with turnover, productivity maintenance will be necessary.
- There are various collateral benefits beyond the base economic 20%. Transformation brings a tide that raises all boats. There are many beneficiaries.
- Applications of the breakthrough can be demonstrated in your shop in a day and/or you can visit an application in process. One day of first-hand experience will do it.
To express interest in auditing an application, contact vitalith@att.net
The Bastid Jailer
One would be insane to argue that legendary sci-fi writer Isaac Asimov was not a prolifically creative person. That’s why I rushed to read this essay he wrote waaay back in 1959 on the subject of creativity: Published for the First Time: a 1959 Essay by Isaac Asimov on Creativity.
As expected, Mr. Asimov did not disappoint. Check out his keen insights on some necessary conditions for tricking the bastid jailer of creativity into unlocking the shackles that keep it out of sight:
Creativity arises from an individual constructing mental connections between two or more ideas which might not ordinarily seem connected. This ability to make cross-associations often comes from eccentric individuals (those willing to fly in the face of reason, authority, and common sense) with a good background in a particular field, and with a keen interest in solving a specific problem in that field.
My feeling is that as far as creativity is concerned, isolation is required. The creative person is, in any case, continually working at it. His mind is shuffling his information at all times, even when he is not conscious of it. The presence of others can only inhibit this process, since creation is embarrassing. For every new good idea you have, there are a hundred, ten thousand foolish ones, which you naturally do not care to display.
Besides the shackles, our bastid jailer controls a powerful anti-creativity force field baked into our minds:
Probably more inhibiting than anything else is a feeling of responsibility. The great ideas of the ages have come from people who weren’t paid to have great ideas, but were paid to be teachers or patent clerks or petty officials, or were not paid at all. The great ideas came as side issues. To feel guilty because one has not earned one’s salary because one has not had a great idea is the surest way, it seems to me, of making it certain that no great idea will come in the next time either.
But we’re not done yet. Our bastid jailer is not alone! He has cleverly deputized the entire human race to be on guard against jailbreaks :
The world in general disapproves of creativity, and to be creative in public is particularly bad. Even to speculate in public is rather worrisome.
Heroes And Admiration
Every person has at least one hero whose work they admire. If you’ve glanced at my “about” page, you may have correctly assumed that one of my heroes is writer/speaker Scott Berkun. I’ve followed Scott and read all of his books since he made the scary leap long ago from a safe job at Microsoft into the unforgiving jungle of self-sufficiency.
I like Scott’s work so much because I think he’s genuine, transparent, sincere, and down-to-earth. In short, his ideas and insights are helpful to his readers. That’s why I got a kick out of this twitter exchange:
Scott’s brand new, kickstarter-funded, book is titled “The Ghost Of My Father“. It’s a radical departure from his other books in that it’s a deeply personal treatise on growing up with an absentee father. Go out and buy it, pronto!
If I ever get my lazy ass out of “blog only” mode and hunker down to write some kind of unsellable book for my own personal satisfaction, Scott will have been a huge influence on the transition.
A Fascinating Conversation
“A Conversation with Bjarne Stroustrup, Carl Hewitt, and Dave Ungar” is the most fascinating technical video I’ve seen in years. The primary focus of the discussion was how to write applications that efficiently leverage multicore processors. Because of the diversity of views, the video is so engrossing that I watched it three times. I also downloaded the MP3 podcast of the discussion and saved it to a USB stick for the drive to/from work.
When pure physics started limiting the enormous CPU clock speed gains being achieved in the 90s, vertical scaling came to an abrupt halt and horizontal scaling kicked into gear. The number of cores per processor started going up, and it still is today.
There was much discussion over the difference between a “lock” and “synchronization“. As the figure below illustrates, main memory is physically shared between the cores in a multicore processor. Thus, even if your programming language shields this fact from you by supporting high level, task-based, message passing instead of low-level cooperative threading with locks, some physical form of under-the-hood memory synchronization must be performed in order for the cores to communicate with each other through shared memory without data races.
Here is my layman’s take on each participant’s view of the solution to the multicore efficiency issue:
- Hewitt: We need new, revolutionary, actor-based programming languages that abandon the traditional, sequential Von Neumann model. The current crop of languages just don’t cut it as the number of cores per processor keeps steadily increasing.
- Ungar: We need incoherent, unsynchronized hardware memory architectures with background cache error correction. Build a reliable system out of unreliable parts.
- Stroustrup: Revolutions happen much less than people seem to think. We need to build up and experiment with efficient concurrency abstractions in layered libraries that increasingly hide locks and core-to-memory synchronization details from programmers (the C++ threads-to-tasks-to-“next?” approach).
Hopelessly Irreducible
Some of the parody accounts on Twitter are hilariously creative. Take “InfoSec Taylor Swift” for example:
The key word in Ms. Swift’s aphorism is “irreducible“. Being one of those things that isn’t objectively measurable (it’s funny how many things in real life are unmeasurable), one man’s “irreducible” is another man’s “reducible“.
I’ve discovered that many people, especially penny-obsessed managers, are so quick to assume and accept irreducibility in a complex system that they don’t even attempt to reduce its complexity:
- It takes time (which directly maps into expense) and hard mental labor to unravel complexity.
- In macho org cultures, irreducible complexity is often seen as intelligent sophistication, a badge of honor, a step toward lofty guru status.
Conversely, it is easier and less time consuming (which again directly maps into expense) to concoct an irreducible complex monolith than it is to thoughtfully build a reducible complex system of smoothly interacting parts.
The #noprograms Revolution
I’ve been developing software in the aerospace and defense industry for 30+ years. Because of the sizes of, and innate System-of-Systems nature of, the solutions in this domain, the processes used to develop them are by necessity, heavyweight. Oh sure, agile/lean techniques can be used effectively in the teeny-tiny-small deep down in the bowels of some of these programs, but to assume “scaling agile” will work in a domain with hundreds of programmers from multiple contractors working on the same distributed system is naive at best, and downright disingenuous at worst.
The most ridiculous examples of inapplicable development practices to the aerospace and defense industry are #noestimates” and “#noprojects“. The “#noprojects” cult is so far off base that they don’t even acknowledge the existence of “programs” – which are a way of organizing a large set of inter-dependent “#noprojects” into, well, a larger grained mission-critical entity worth tens of millions of dollars. It’s like before there were classes and namespaces(packages) added to a programming language to accommodate increasing software system size, there were only “functions” for organizing the structure of a program – and having functions as your only organizing mechanism doesn’t scale well to large software systems.
Hell, the #noprojects people are akin to #noclasses and #nonamespaces people, of which there are thankfully, #nomembers. Really hardcore #noprojects people are perhaps even more loony. They are equivalent to a hypothetical #nofunctionsallowed crowd that demands monolithic, straight-line code only. Line number 1 straight to line number 5,000,000 – and you can’t use loops or “ifs” because they don’t add value and #nofunctionsallowed is all about “maximizing the amount of work not done“.
But hey, if you don’t need any “projects” to build a successful product from the gecko, then by extrapolation you don’t need any “programs” for organizing your projects. Hence, the inimitable BD00 proposes to “scale up” the “#noprojects” movement. We’ll start a revolutionary #noprograms movement, or equivalently, #justcode . We’ll leapfrog both the #noestimates and #noprojects movements at once. W00t!
Dude, Cut Me Some Slack
Since I enjoyed reading Tom DeMarco’s “Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency” years ago, this diagram in Jamshid Gharajedaghi’s “Systems Thinking: Managing Chaos and Complexity” brought back some fond memories of that book:
The diagram shows the slow, insidious erosion in flexibility that occurs in a complex system when efficiency and optimization initiatives are relentlessly applied to the system by its uninformed stewards. As the “slack” is stretched out of the system due to increasing internal pressure, it: 1) loses its robustness to external stressors, 2) the tension between connected nodes increases, and 3) the inter-node couplings harden. At the system breaking point, one or more of the connections crack open, the nodes fly apart, and the conglomeration ceases to function as a whole – a system. I hate when that happens!
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 