Archive
Hindsight-Based
Here’s yet another insightful paragraph from William Livingston’s “Design For Prevention“:
An Attempt At Legitimacy
Regular readers of this bogus blog know that one of my differentiators is the dorky graphics that I use to communicate my wildly distorted and fantastical views of life. But being a lazy ass and unscrupulous dolt, I’ve pulled quite a few graphic clips off the web without asking for permission or giving attribution. Here’s one of my latest DICster faves:
In trying to assuage my guilt for stealing clips, I used tineye.com to track down the talented creator of the artwork – Mr. George Coghill. I e-contacted him a few weeks ago, confessed my sin, and asked him how I could make it right. Alas, I haven’t heard back from him yet.
BTW, I don’t look anything like the DICster icon…..
Scripted Behavior
Since I’m on a mini-roll hoisting excerpts from W. L. Livingston’s D4P book, here’s yet another one (I had to type the example in by hand because it only appears in the print version and not in the pdf. D’oh!):
In project review meetings, the whimsical plan, riddled with entropy and misinformation, is used as gospel to measure “actual” progress. Since everyone at the meeting knows the measurement is useless as a control, it becomes an instrument of management to manage the project. Invariably, management directs a get-well plan be devised to get back on the horribly-flawed milestone plan. Of course, the get-well plan is composed in the same toxic way.
The attending executive proclaims “If you don’t get this mess back on schedule by tomorrow, I’ll get somebody who can.” Everyone has heard this proclamation of executive out-of-control. The impact of this act of desperation on the project is wholesale CYA (Cover Your Ass) and subreption. Information available for forecasting progress becomes nothing but calculated lies. That’s where attempts to defy natural law land you.
Matched Vs. Mismatched
If for some strange reason you wasted some precious time and read yesterday’s post, you might have wondered what this “mismatch” thing is all about. Hopefully, this excerpt from the forthcoming 2012 edition of Bill Livingston’s D4P book (not the layman’s D4P4D) should shed some light on the mystery:
Naive outrage? Lack of understanding? Hmm. Not BD00. He knows everything.
Keystone Koppers
Here’s just one entertaining excerpt from Bill Livingston’s darkly insightful and mind-bending book, “D4P4D“:
The key word in the whole excerpt is “mismatch“. When there is a “match“, all is well, and “business as usual” gets the job done effectively and efficiently.
So, whadya think? Fearful fact? Funny fiction? A touch of both?
A Blank Stare In Return
In a previous life, I once was commiserating with a manager about how difficult and time consuming it was to keep up with technological change in the software development industry. She said “That’s why I went into management“. After sharing a chuckle, I asked her if there were any other reasons for movin’ on up. I received a blank stare in return.
In a previous life, I once was talking to a software lead and hinted that maybe he should do more than watching schedules and doling out tasks (like cutting some code from time to time or keeping the technical documentation in synch with the code or doing some exploratory testing on the code base or taking on the role of buildmaster). I received a blank stare in return.
In a previous life, I once asked a software lead why he moved out of “coding” and into the periphery of management. He said: “For more money“. When I asked him if there were any other reasons, I received a blank stare in return.
At least they were honest. They could’ve offered up the classic management textbook response: “to take on more responsibility“. Better yet, they could’ve said “to help people do their jobs better” or “to help improve the quality of our processes by reducing red tape and eliminating low value steps“.
So, are they “selfish” people? Nah. This ubiquitous behavior is simply a side effect of how the vast majority of reward and power distribution systems are structured in hierarchical orgs. It’s been that way for 100 years and it looks like it will stay that way for the next 100 years. But then again, maybe not.
Brain-Bustingly Hard
Unsettlingly, I admire the cross-disciplinary work of William L. Livingston because:
- It’s difficult to place into a nice and tidy category (systems thinking? social science? philosophy?).
- It resonates with “something” inside me but it’s brain-bustingly hard to absorb, understand, and re-communicate.
- The breadth of his vocabulary is astonishing.
- He doesn’t give a shit about becoming rich and famous.
- He digs up quotes/paragraphs from obscure, but insightful “mentors” from the past.
As the boxes below (plucked from the D4P4D) show, Gustave Le Bon is one of those insightful mentors, no?
A lot of Mr. Le Bon’s work is available for free online at project Gutenberg.
Misapplication Of Partially Mastered Ideas
Because the time investment required to become proficient with a new, complex, and powerful technology tool can be quite large, the decision to design C++ as a superset of C was not only a boon to the language’s uptake, but a boon to commercial companies too – most of whom developed their product software in C at the time of C++’s introduction. Bjarne Stroustrup‘s decision killed those two birds with one stone because C++ allowed a gradual transition from the well known C procedural style of programming to three new, up-and-coming mainstream styles at the time: object-oriented, generic, and abstract data types. As Mr. Stroustrup says in D&E:
Companies simply can’t afford to have significant numbers of programmers unproductive while they are learning a new language. Nor can they afford projects that fail because programmers over enthusiastically misapply partially mastered new ideas.
That last sentence in Bjarne’s quote doesn’t just apply to programming languages, but to big and powerful libraries of functionality available for a language too. It’s one challenge to understand and master a language’s technical details and idioms, but another to learn network programming APIs (CORBA, DDS, JMS, etc), XML APIs, SQL APIs, GUI APIs, concurrency APIs, security APIs, etc. Thus, the investment dilemma continues:
I can’t afford to continuously train my programming workforce, but if I don’t, they’ll unwittingly implement features as mini booby traps in half-learned technologies that will cause my maintenance costs to skyrocket.
BD00 maintains that most companies aren’t even aware of this ongoing dilemma – which gets worse as the complexity and diversity of their product portfolio rises. Because of this innocent, but real, ignorance:
- they don’t design and implement continuous training plans for targeted technologies,
- they don’t actively control which technologies get introduced “through the back door” and get baked into their products’ infrastructure; receiving in return a cacophony of duplicated ways of implementing the same feature in different code bases.
- their software maintenance costs keep rising and they have no idea why; or they attribute the rise to insignificant causes and “fix” the wrong problems.
I hate when that happens. Don’t you?
Highly Available Systems == Scalable Systems
In this QCon talk: “Building Highly Available Systems In Erlang“, Erlang programming language creator and highly-entertaining speaker Joe Armstrong asserts that if you build a highly available software system, then scalability comes along for “free” with that system. Say what? At first, I wanted to ask Joe what he was smoking, but after reflecting on his assertion and his supporting evidence, I think he’s right.
In his inimitable presentation, Joe postulates that there are 6 properties of Highly Available (HA) systems:
- Isolation (of modules from each other – a module crash can’t crash other modules).
- Concurrency (need at least two computers in the system so that when one crashes, you can fix it while the redundant one keeps on truckin’).
- Failure Detection (in order to fix a failure at its point of origin, you gotta be able to detect it first)
- Fault Identification (need post-failure info that allows you to zero-in on the cause and fix it quickly)
- Live Code Upgrade (for zero downtime, need to be able to hot-swap in code for either evolution or bug fixes)
- Stable Storage (multiple copies of data; distribution to avoid a single point of failure)
By design, all 6 HA rules are directly supported within the Erlang language. No, not in external libraries/frameworks/toolkits, but in the language itself:
- Isolation: Erlang processes are isolated from each other by the VM (Virtual Machine); one process cannot damage another and processes have no shared memory (look, no locks mom!).
- Concurrency: All spawned Erlang processes run in parallel – either virtually on one CPU, or really, on multiple cores and processor nodes.
- Failure Detection: Erlang processes can tell the VM that it wants to detect failures in those processes it spawns. When a parent process spawns a child process, in one line of code it can “link” to the child and be auto-notified by the VM of a crash.
- Fault Identification: In Erlang (out of band) error signals containing error descriptors are propagated to linked parent processes during runtime.
- Live Code Upgrade: Erlang application code can be modified in real-time as it runs (no, it’s not magic!)
- Stable Storage: Erlang contains a highly configurable, comically named database called “mnesia” .
The punch line is that systems composed of entities that are isolated (property 1) and concurrently runnable (property 2) are automatically scalable. Agree?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 