Archive
They’ve Finally Done It, They Are In Control!
Oh ratz! BD00 wishes he concocted this brilliant “Planet Of The Apes” parody T-shirt:
But alas, BD00 didn’t create the masterpiece. The Random Manager team did. Damn it! Here’s the BD00 rip off version:
Ill Equipped And Discounted
In a 2012 slideshare deck that built a case for a hostile takeover of Blackberry maker RIM (Research In Motion), venture capitalist Robin Chan hoisted this foil of the smugly smiling C-level dudes running the show at DIM (Disaster In Motion):
To add insult to injury, Mr. Chan writes:
D’oh! C-Level infallibles don’t like being characterized as “ill equipped” and “discounted“. However, fear not for the dissed DIMwit royalty. Since DIM recently announced plans to frantically find a buyer for their struggling business, these execs will make out just fine. The golden parachutes will be doled out, they’ll hop on a plane to their next destination, glide right into the C-suites at their next gigs, and have their smiling picture taken for the next annual report. Who sez performance matters?
Tradition and Progress
Continuing on with a series of posts fueled by the inspirational content in Scott Berkun’s newly minted “The Year Without Pants“, let’s explore the relationship between tradition and progress:
There is nothing wrong with tradition until you want progress: progress demands change, and change demands a reevaluation of what the traditions are for and how they are practiced…. The responsibility of people in power is to continually eliminate useless traditions and introduce valuable ones. An organization where nothing ever changes is not a workplace but a living museum. – Scott Berkun
In poorly led institutions, as the number of management (“management” is simply a euphemism for “control“) layers increases, new “special interest” traditions are continuously introduced into the environment whilst old and useless rituals are rarely eliminated. Policies, directives, processes, procedures, taxes, fees, laws – pick your poison. The pile of behavior constraining rules just gets bigger and bigger, suffocating all intrinsic motivation and instilling learned helplessness. Damn, that Kafka dude got it right. So did Ackoff:
It is easier to start something new than it is to stop something old – Russell Ackoff.
The Confusion Of Roles
Scott Berkun’s books have always been lucrative gold mines for bloggers wanting to explore novel ideas and insights. His latest release, “The Year Without Pants“, is no different.
In TYWP, Scott discloses a major cultural malady that plagues corpo America: “The Confusion Of Roles“.
One major mistake Schneider (Automattic Inc’s CEO) had seen was how companies confused supporting roles, like legal, human resources, and information technology, with product creation roles like design and development. Product creators are the true talent of any corporation, especially one claiming to bet on innovation. The other roles don’t create products and should be there to serve those who do. A classic betrayal of this idea is when the IT department dictates to creatives what equipment they can use. If one group has to be inefficient, it should be the support group, not the creatives. If the supporting roles, including management, dominate, the quality of products can only suffer. – Scott Berkun
The “Confusion Of Roles” is simply not a problem at Automattic Inc. That’s because there are no legal, human resources, finance, quality assurance, or information technology silos within the flat-as-a-pancake company.
Well, that’s all fine and dandy for a cozy, small company like Automattic. But there is no cure for the “role confusion” disease in big borgs like yours, right? Bzzzzt!
HCLT CEO Vineet Nayar wrote about the exact same productivity and morale killer in his shockingly titled “Employees First, Customers Second” book. Taking the bull by the horns, Vineet corrected the “confusion of roles” epidemic at his 30,000 person Leviathon by inverting the pyramid and instituting a transparent system of reverse accountability called the Smart Service Desk (SSD) .
The SSD is where front line employees can submit problem tickets against the (so-called) support functions. Each ticket has a deadline date and the submitter is the ultimate judge of results – not some self-important manager. Shortly after its introduction, the SSD was receiving tickets at a rate of 30,000 per month – one per employee. D’oh!
Why, you may be asking, aren’t there more “unconfusion-of-roles” change efforts taking place in the land of a million pointy hierarchies? It’s because the pinnacle dwellers who rule the roost don’t see it as a problem at all. It’s the way it is because it’s always been that way and, more importantly, it’s the way it’s supposed to be.
The Drooping Progress Syndrome
When a new product development project kicks off, nobody knows squat and there’s a lot of fumbling going on before real progress starts to accrue. As the hardware and software environment is stitched into place and initial requirements/designs get fleshed out, productivity slowly but surely rises. At some point, productivity (“velocity” in agile-ese) hits a maximum and then flattens into a zero slope, team-specific, cadence for the duration. Thus, one could be led to believe that a generic team productivity/progress curve would look something like this:
In “The Year Without Pants“, Scott Berkun destroys this illusion by articulating an astute, experiential, observation:
This means that at the end of any project, you’re left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them). It should never be a surprise that progress seems to slow as the finish line approaches, even if everyone is working just as hard as they were before. – Scott Berkun
Scott may have forgotten one class of thing that BD00 has experienced over his long and un-illustrious career – things that need to get done but aren’t even in the work backlog when deployment time rolls in. You know, those tasks that suddenly “pop up” out of nowhere (BD00 inappropriately calls them “WTF!” tasks).
Nevertheless, a more realistic productivity curve most likely looks like this:
If you’re continuously flummoxed by delayed deployments, then you may have just discovered why.
Related articles
- The Year Without Pants: An interview with author Scott Berkun (oldienewbies.wordpress.com)
- Scott Berkun Shares Advice for Writers Working Remotely (mediabistro.com)
- A Book in 5 Minutes: “The Year without Pants: WordPress.com and the Future of Work” (tech.co)
A Concrete Agile Practices List
Finally, I found out what someone actually thinks “agile practices” are. In “What are the Most Important and Adoption-Ready Agile Practices?”, Shane-Hastie presents his list:
Kudos to Shane for putting his list out there.
Ya gotta love all the “explicit definition of done” entries (“Aren’t you freakin’ done yet?“). And WTF is “Up front architecture” doing on the list? Isn’t that a no-no in agile-land? Shouldn’t it be “emergent architecture“? And no kanban board entry? What about burn down charts?
Alas, I can’t bulldozify Shane’s list too much. After all, I haven’t exposed my own agile practices list for scrutiny. If I get the itch, maybe I’ll do so. What’s on your list?
Pragmatically Feasible?
From the MISRA web site:
The Motor Industry Software Reliability Association (MISRA), is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems.
While browsing through the MISRA C++:2008 standard, I came across this not-unexpected requirement:
I don’t know enough about the standard to know if it’s true, but I interpret this requirement as banning not only the use of “new/delete“, but also as banning the use of the dynamically managed STL container abstractions (vectors, lists, sets, maps, queues) and, hence, the many standard library algorithms that operate on them. I wonder what the MISRA Java specification, if there is one, says about dynamic memory allocation.
If my interpretation of 18-4-1 is correct, then the requirement can severely jack up the cost, schedule, and technical risks of any software component that is required to be compliant with the specification. For non-trivial applications requiring more than low-level, statically allocated arrays…..
Complexity is pushed out of the language and into the application code. The semantics of language features are far better specified than the typical application code. – Bjarne Stroustrup & Kevin Carroll
Because of the safety-critical nature of embedded automotive software, I can understand the reasoning behind the no-dynamic-memory-allocation requirement. But is it pragmatically feasible in today’s world; especially since software components keep getting larger and commensurately more complex over time? In other words, is it one of those requirements that doesn’t scale? Is it too Draconian?
For those C++ programmers who work in the automotive industry and happen to stumble upon this blog (which will probably be none), what has been your experience with this MISRA requirement and some of the other similarly unsettling requirements in the specification? Are “waivers” often asked for and granted? Is it an unspoken truth that people/companies pay public lip service to the requirement but privately don’t comply?
The Biggest Cheerleader
Herb Sutter is by far the biggest cheerleader for the C++ programming language – even more so than the language’s soft spoken creator, Bjarne Stroustrup. Herb speaks with such enthusiasm and optimism that it’s infectious.
In his talk at the recently concluded GoingNative2013 C++ conference, Herb presented this slide to convey the structure of the ISO C++ Working Group 21 (WG21):
On the left, we have the language core and language evolution working groups. On the right, we have the standard library working group.
But wait! That was the organizational structure as of 18 months ago. As of now, we have this decomposition:
As you can see, there’s a lot of volunteer effort being applied to the evolution of the language – especially in the domain of libraries. In fact, most of the core language features on the left side exist to support the development of the upcoming libraries on the right.
In addition to the forthcoming minor 2014 release of C++, which adds a handful of new features and fixes some bugs/omissions from C++11, the next major release is slated for 2017. Of course, we won’t get all of the features and libraries enumerated on the slide, but the future looks bright for C++.
The biggest challenge for Herb et al will be to ensure the conceptual integrity of the language as a whole remains intact in spite of the ambitious growth plan. The faster the growth, the higher the chance of the wheels falling off the bus.
“The entire system also must have conceptual integrity, and that requires a system architect to design it all, from the top down.” – Fred Brooks
“Who advocates … for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks
I’m not a fan of committees in general, but in this specific case I’m confident that Herb, Bjarne, and their fellow WG21 friends can pull it off. I think they did a great job on C++11 and I think they’ll perform just as admirably in hatching future C++ releases.
Goal Setting
Given the generic control system model below, how can we improve the performance of an underachieving production system?
One performance improvement idea is to make the goal directly visible to the production system; as opposed to indirectly via the policy/process actions of the actuators.
A meta-improvement on this idea is to allow the production system constituents direct involvement in the goal setting process.
It seems to make naive sense, doesn’t it? Well, it does unless the goal is some arbitrarily set financial target (“increase market share by 10%“, “decrease costs by 5%“, “increase profits by 25%“) pulled out of a hat to temporarily anesthesize Wall Street big-wigs.
Related articles
- Who’s Controlling The Controller? (bulldozer00.com)
- Unobservable, Uncontrollable (bulldozer00.com)
Unobservable, Uncontrollable
Piggybacking on yesterday’s BS post, let’s explore (and make stuff up about) a couple of important control system “ilities“: observability and controllability.
First, let’s look at a fully functional control system:
As long as the (commands -> actions -> CQs -> perceptions) loop of “consciousness” remains intact, the system’s decision maker(s) enjoy the luxury of being able to “control the means of production“. Whether this execution of control is effective or ineffective is in the eye of the beholder.
As the figure below illustrates, the capability of decision-makers to control and/or observe the functioning of the production system can be foiled by slicing through its loop of “consciousness” at numerous points in the system.
From the perspective of the production system, simply ignoring or misinterpreting the non-physical actions imposed on it by the actuators will severely degrade the decision maker’s ability to control the system. By withholding or distorting the state of the important “controlled quantities” crucial for effective decision making, the production system can thwart the ability of the decision maker(s) to observe and assess whether the goal is being sought after.
In systems where the functions of the components are performed by human beings, observability and controllability get compromised all the time. The level at which these “ilities” are purposefully degraded is closely related to how fair and just the decision makers are perceived to be in the minds of the system’s sensors, actuators, and (especially the) producers.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
