Archive
Searching For A Title
Look at the e-mail gift that BD00 recently received from a shy cohort in crime:
I’ve been searching for a title to the book that I probably won’t ever write. TEWKTHN seems as good as any. Got any other suggestions?
Will Work For….
Perhaps disturbingly, I’ve always been curious about the factors and causes of individual and (especially) group psychopathy. Thus, this Ronald Schouten piece, “Psychopaths on Wall Street” (which is a PR pitch for his forthcoming book “Almost a Psychopath“), caught my attention. Specifically, Mr. Schouten’s “good news” paragraph triggered a sinister, internal BD00 “LOL!“.
But there is good news. First of all, it is possible to screen out “almost” and “full-blown” psychopaths during the hiring process and after. Some of the key indicators are:
Glibness and superficial charm (BD00?)
Lack of empathy (BD00?)
Consistent decisions in their self interest, even where it is ethically questionable (BD00?)
Chronic, sometimes transparent lies, even with regard to minor things (BD00?)
Lack of remorse (BD00?)
Failure to take responsibility for their actions, and instead blaming others (BD00?)
Shallow emotions (BD00?)
Ignoring responsibilities (BD00?)
Persistent focus on gratifying their own needs at the expense of others (BD00?)
Conning and manipulative behavior (BD00?)
How can one possibly confirm or disconfirm these traits during a job interview – especially since psychopaths are brilliant at masking their agendas? But wait! On second glance, the list looks like it could serve as a bona fide set of prerequisites for executive team membership at Enron and Goldman Sux type borgs, no?
Product Line Blueprint
Here it is, the blueprint (patent pending) you’ve been waiting for:
Need a little less abstraction? Well, how about this refinement:
Piece of cake, no? It’s easy to “figure out“:
- the number of layers needed in the platform,
- the functionality and connectivity within and between each of the layers in the stack
- the granularity of the peer entities that go into each layer and which separates the layers
- the peer-to-peer communication protocols and dependencies within each layer
- the interfaces provided by, and required by, each layer in the stack
- what your horizontally, integrate-able App component set should be for specific product instantiations
- how much time, how much money, and how many people it will take to stand up the stack
- how many different revenue-generating product variants will initially be needed for economic viability
- how to secure all the approvals needed
- how to manage the inevitable decrease in conceptual integrity and increase in entropy of the product factory stack over time – the maintenance problem
Perhaps easiest of all is the last bullet; the continuous, real-time management of the core asset base IF the product factory stack is actually built and placed into operation. After all, it’s not like trying to herd cats, right?
Please feel free to use this open source (LOL!) product line template to instantiate, build, and exploit your own industry and domain specific product line(s). Enough intellectualizing and “strategizing” about doing it in useless committees, task forces, special councils, tiger teams, and blue ribbon panels. There’s money to be made, joy to be distributed, and toes to be stepped on; so just freakin’ do it.
Is this post still too abstract to be of any use? Let’s release some more helium from our balloon and descend from the sky just a wee bit more so that we can get a glimpse of what is below us. Try out “revision 0” of this blueprint instantiation for a hypothetical producer of radar systems:
Did you notice the increase in tyranny of detail and complexity as we transcended the 3 levels of abstraction in this post? Well, it gets worse if we continue on cuz we don’t yet have enough information, knowledge, or understanding to start cutting code, building, testing, and standing up the stack – not nearly enough. Thus, let’s just stop right here so we can retain a modicum of sanity. D’oh! Too late!
Fellow Tribe Members
Being a somewhat skeptical evaluator of conventional wisdom myself, I always enjoy promoting heretical ideas shared by unknown members of my “tribe“. Doug Rosenberg and Matt Stephens are two such tribe members.
Waaaay back, when the agile process revolution against linear, waterfall process thinking was ignited via the signing of the agile manifesto, the eXtreme Programming (XP) agile process burst onto the scene as the latest overhyped silver bullet in the software “engineering” community. While a religious cult that idolized the infallible XP process was growing exponentially in the wake of its introduction, Doug and Matt hatched “Extreme Programming Refactored: The Case Against XP“. The book was a deliciously caustic critique of the beloved process. Of course, Matt and Doug were showered with scorn and hate by the XP priesthood as soon as the book rolled off the presses.
Well, Doug and Matt are back for their second act with the delightful “Design Driven Testing: Test Smarter, Not Harder“. This time, the duo from hell pokes holes in the revered TDD (Test Driven Design) approach to software design – which yet again triggered the rise of another new religion in the software community; or should I say “commune“.
BD00’s hat goes off to you guys. Keep up the good work! Maybe your next work should be titled “Lowerarchy Design: The Case Against Hierarchy“.
Up, Down, Sideways
In order for a tree to remain viable throughout its lifetime, it must grow upwards, sideways (think leaves), and downward (think roots). In BD00’s tortured mind, a lot of people seem myopically focused solely on growing up.
Dream, Mess, Catastrophe
To build high quality, successful, long-lived, “Big” software, you must design it in terms of layers (that’s why the ISO ISO model for network architecture has 7, crisply defined layers). If you don’t leverage the tool of layering (and its close cousin – leveling) in an attempt to manage complexity, then: your baby won’t have much conceptual integrity; you’ll go insane; and you’ll be the unproud owner of a big ball of mud that sucks down maintenance funds like a Dyson and may crumble to pieces at the slightest provocation. D’oh!
The figure below shows a reference model for a layered application. Note that even though we have a neat stack, we can’t tell if we have a winner on our hands.
By adding the inter-layer dependencies to the reference architecture, the true character of our software system will be revealed:
In the “Maintenance Dream“, the inter-layer APIs are crisply defined and empathetically exposed in the form a well documented interfaces, abstractions, and code examples. The programmer(s) of a given layer only have to know what they have to provide to the users above them and what the next layer below lovingly provides to them. Ah, life is good.
Next, shuffle on over to the “Maintenance Mess“. Here, we have crisply defined layers, but the allocation of functionality to the layers has been hosed up ( a violation of the principle of “leveling“) and there’s a beast in the making. Thus, in order for App Layer programmers to be productive, they have to stuff their head with knowledge/understanding of all the sub-layer APIs to get their jobs done. Hopefully, their heads don’t explode and they don’t run for the exits.
Finally, skip on over to the (shhh!) “Maintenance Catastrophe“. Here, we have both a leveling mess and an incoherent set of incomprehensible (to mere mortals) inter-layer APIs. In the worst case: the layers aren’t discernible from one another; it takes “forever” to on-board new project members; it takes forever to fix bugs; it takes forever to add features; and it takes an heroic effort to keep the abomination alive and kicking. Double D’oh!
Forever == Lots Of Cash
In orgs that have only ever created “Maintenance Messes and Catastrophies“, since they’ve never experienced a “Maintenance Dream“, they think that high maintenance costs, busted schedules, and buggy releases are the norm. How do you explain the color green to someone who’s spent his/her whole life immersed in a world of red?
Behind The Scenes
In really dysfunctional orgs, do you think much of this goes on……?
Complexity, Evolution, Growth
Is an increase in complexity required for evolution to occur?
Likewise, is an increase in complexity required for growth to occur?
Fill In The Blanks
While doodling around with my e-sketchpad on a quiet Sunday morning, I conjured up the series of drawings you see below. However, when I tried to make up a BS story that tied the series together in a semi-coherent manner, I failed.
Rather than throwing the series of pics away, it occurred to me to ask for your help. So, can you help me out by filling in the blanks? Think of my plea for your right-brained help as a constrained exercise in creative writing.
The comments section is now open! Please come on down and give it a shot.
—————————————————————————————————————————
<<blank 1>>
<<blank2>>
<<blank3>>
<<blank4>>
<<blank5>>
Lacking Smarts
Check out the title of this article and have a LOL with (or at) BD00: “People Aren’t Smart Enough for Democracy to Flourish, Scientists Say“.
The research, led by David Dunning, a psychologist at Cornell University, shows that incompetent people are inherently unable to judge the competence of other people, or the quality of those people’s ideas.
D’oh! Too stupid to judge. That’s BD00 in a nutshell when he attempts to unfairly scald the guild of management and its continued, often subtle, application of Tayloristic techniques in the 21st century.
…democracies rarely or never elect the best leaders. Their advantage over dictatorships or other forms of government is merely that they effectively prevent lower-than-average candidates from becoming leaders.
If that’s “merely” true for democracies, then un-democracies must merely suck. How well do you think undemocratic boards of directors do in choosing executives and how well undemocratic executives do in anointing subordinate managers and how well undemocratic managers do in hiring DICsters and how well DICs do in….? Oops, I almost forgot that DICs aren’t allowed to choose or anoint.
Of course, this research on incompetence doesn’t apply to the elites who run institutions because boards of directors, executives, and managers are infallibly competent in their profession.
Ya gotta love this Wikipedia definition of anointment:
To anoint is to pour or smear with perfumed oil, milk, water, melted butter or other substances, a process employed ritually by many religions. People and things are anointed to symbolize the introduction of a sacramental or divine influence, a holy emanation, spirit, power or God.
At my anointment, I want to be smeared with… peanut butter and melted Godiva chocolate. How about you? What’s your substance of choice – assuming you have a choice?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 