Archive
Sergeant Schultz Defense
We’ve heard it before, we’re hearing it now from formerly unassailable media mogul Rupert Murdoch, and we’ll hear it again from other self-important papal figures. Yawn.
What will we hear, you ask? Well, it’s the ubiquitous Sergeant Schultz defense: “I hear nothing, I see nothing, I know nothing“. But ya know, the hot shot dudes who whip out this get-out-of-jail-free card may actually be right. If they “skillingfully” setup their borg’s structure and culture so that they can’t know, then they won’t.
Chicken Or Egg?
In this cawntry, you gotta make-uh duh money first. Den, when you getta duh money, you getta duh power. – Tony “Scarface” Montana
Which comes first, power or wealth? Although Bulldozer00 agrees with scarface, it really doesn’t matter. When you accumulate enough of one, the other is sure to follow.
Alarmin’ Larman
Recently, I listened to an interview with Craig Larman on the topic of “Scaling Scrum To Large Organizations“.
Here is what I liked about Mr. Larman’s talk:
- He didn’t use the term “management“. He repeatedly used the term “overhead management” to emphasize the wastefulness of maintaining these self-important middle org layers.
- He predicted that the dream of retaining high paying, “spreadsheet and Microsoft Project overhead management jobs” in developed countries designed to watch over subservient code monkeys in low labor rate, third world countries would not come to fruition.
- He predicted that the whole scale adoption of agile processes like “Scrum” and “Lean” would lead to the demise of the roles of “project manager” and “program manager” in software projects.
- He recommended ignoring ISO and CMMI certifications and assessments. Roll up your sleeves and directly read/inspect the source code of any software company you’re considering partnering with or buying from.
There is one thing that bothered me about his talk. I’m not a Scrum process expert, but I don’t understand the difference between the cute sounding “Scrum Coach/Scrum Master” roles and the more formal sounding “Project Manager/Program Manager” roles. Assuming that there’s a huge difference, I can foresee clever overhead managers donning the mask of “Scrum Master” and still behaving as self-important, know-it-all, command and control freaks. Of course, they can only get away with preserving the unproductive status quo (while espousing otherwise) if the executives they work for are clueless dolts.
If you’re so inclined, give the talk a listen and report your thoughts back here.
Steered, Or Unsteered
Which path are you on? Have you ever been lucky enough to travel on the high road even once?
Tainted Observations
Based on his rudimentary understanding of quantum physics, BD00 thinks there is no such thing as a truly objective observer. Every observation is tainted by the instantaneous and unconscious coupling of personal (a.k.a subjective) beliefs, desires, and fears to the observed. The closer one is to a perceived “mess“, the more the taint.
Findings And Recommendations
The National Academy of Sciences is a private, nonprofit, self-perpetuating society of distinguished scholars engaged in scientific and engineering research, dedicated to the furtherance of science and technology and to their use for the general welfare. Upon the authority of the charter granted to it by the Congress in 1863, the Academy has a mandate that requires it to advise the federal government on scientific and technical matters.
Via the publicly funded National Academies mailing list, I found out that the book “Critical Code: Software Producibility for Defense“ was available for free pdf download. Despite being committee written, the book is chock full of good “findings” and “recommendations” that are not only applicable to the DoD, but to laggard commercial companies as well.
Not surprisingly, because of the exponentially growing size of software-centric systems and the need for interoperability, “architecture” plays a prominent role in the book. Here are some of my favorite committee findings and recommendations:
Finding 3-1: Industry leaders attend to software architecture as a first-order decision, and many follow a product-line strategy based on commitment to the most essential common software architectural elements and ecosystem structures.
Finding 3-2: The technology for definition and management of software architecture is sufficiently mature, with widespread adoption in industry. These approaches are ready for adoption by the DoD, assuming that a framework of incentives can be created in acquisition and development efforts.
Recommendation 3-2: This committee reiterates the past Defense Science Board recommendations that the DoD follow an architecture driven acquisition strategy, and, where appropriate, use the software architecture as the basis for a product-line approach and for larger-scale systems potentially involving multiple lead contractors.
The DoD funded Software Engineering Institute, located at Carnegie Mellon University, has produced a lot of good work on software product lines. Jan Bosch’s “Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach” and Chapters 14 and 15 in Bass, Clements, and Kazman’s “Software Architecture in Practice” are excellent sources of information. The stunning case study of Celsius Tech really drove the point home for me.
My Erlang Learning Status – IV
I haven’t progressed forward at all on my previously stated goal of learning how to program idiomatically in Erlang. I’m still at the same point in the two books (“Erlang And OTP In Action“; “Erlang Programming“) that I’m using to learn the language and I’m finding it hard to pick them up and move forward.
I’m still a big fan (from afar) of Erlang and the Erlang community, but my initial excitement over discovering this terrific language has waned quite a bit. I think it’s because:
- I work in C++ everyday
- C++11 is upon us and learning it has moved up to number 1 on my priority list.
- There are no Erlang projects in progress or in the planning stages where I work. Most people don’t even know the language exists.
Because of the excuses, uh, reasons above, I’ve lowered my expectations. I’ve changed my goal from “learning to program idiomatically” in Erlang to finishing reading the two terrific books that I have at my disposal.
Note: If you’re interested in reading my previous Erlang learning status reports, here are the links:
Schein On You Crazy Diamond
Edgar Schein is a well known MIT expert on the topic of organizational culture. In “A Corporate Climate of Mutual Help“, Mr. Schein describes his method for taking on the huge challenge of changing institutional culture. Wisely, he harbors a:
deep respect for the power and legitimacy of ingrained assumptions and attitudes that people develop together gradually.
While talking about the approach that CGHs, BUTTs, and SCOLs typically pursue when trying to improve their CLORG‘s culture, he sez:
they think that to change culture, you simply introduce a new culture and tell people to follow it. All you’ve done is stated the obvious, like “We’re for motherhood.”
Mr. Schein goes further in peeling the onion:
It’s the very nature of authority to say, “Don’t be a squeaky wheel. You made your point, but we’re going to go ahead anyway. I don’t want to hear any more.”
In lieu of the easy “dictate-and-skidaddle-away” strategy, Mr. Schein’s painstakingly thoughtful and time consuming approach to cultural change (which makes it unacceptable to most institutional SCOLs) is:
…one of observation, inquiry, and leverage.This means observing the ways in which an organization’s employees act; deducing (or inquiring about) the ways they think; and putting in place small behavioral changes that lead them, bit by bit, to think about things differently.
Notice that to execute Mr. Schein’s strategy requires sustained commitment, hard work, and empathy. You know, those traits that SCOLs demand from their subordinates but not themselves.
So, why is designing and implementing a healthy culture becoming more and more important in this era of social networking and instantaneous connectivity? It’s because:
…work in many companies is getting more complex, and subordinates have more relative power by virtue of their specialized expertise. If they choose to not tell the boss about problems, the company will never know that there’s an issue until it’s too late. The people with the most authority and established knowledge must make the others feel psychologically safe; everyone will speak up freely when something is wrong.
Of course, if institutional leaders auto-assume that their culture matches the esprit de corps they espouse it to be, then they don’t have a clue that it needs maintaining or (heaven forbid) improving. They then deserve what they get – a deterioration in the quality of work life for all (which includes themselves), which leads to increased apathy at the workface, which leads to decreased commitments to efficiency and innovation, which leads to a degradation in the borg’s products and services, which leads to an incremental (and undetectable) decline in long term financial viability….. until it’s too late and a hairball crisis appears seemingly out of nowhere.
Doc Maturity?
In his classic and highly referenced but much vilified paper, “Managing The Development Of Large Software Systems“, Winston Royce says:
Occasionally I am called upon to review the progress of other software design efforts. My first step is to investigate the state of the documentation. If the documentation is in serious default my first recommendation is simple. Replace project management. (D’oh!)
Before going further, let me establish the “context” of the commentary that follows so that I can make a feeble attempt to divert attacks from any extremist agilistas who may be reading this post. Like Mr. Royce, I will be talking about computationally-intensive software intended for use in these and other closely related types of application domains:
spacecraft mission planning, commanding, and post-flight analysis
Ok, are we set to move on with his shared contextual understanding? Well then, let’s go!
The figure below shows what should happen on a well run, large, defense/aerospace industry system development project. As the recorded info artifact set matures (see the post-post note below), productivity increases and the need for face-to-face communication decreases (but never goes to zero ala the “over-the-wall” syndrome).
Using this graph as a reference point, here’s what often happens, no?
On big, complex projects, mature but incomplete/inconsistent/ambiguous documentation tends to cause an unmanageable increase in face-to-face communication frequency (and decrease in face-to-face communication quality) as schedule-pressured people frantically try to figure out what needs to be built and what elements they’re personally responsible for creating, building, and integrating into the beast. Since more and more time is spent communicating inefficiently, less time is available for productive work. In the worst case, productivity plummets to zero and all subsequent investment dollars go down the rat hole…. until the project “leaders” figure out how to terminate the mess without losing face.
Note: Since “maturity” normally implies “high quality”, and that’s not what I’m trying to convey on the x axis, I tried to concoct a more meaningful x axis label. “Documentation Quantity” came to mind, but that doesn’t fit the bill either because it would imply that quantity == quality in the first reference graph. Got any suggestions for improvement?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 