A Fascination With Governance

If a little is good, then a bunch must be better, until it isn’t.  I was having a conversation on the train the other day on the way home from work. I was sitting with an acquaintance that I ride with from time to time and we were both complaining about the week we were having. And we started to realize that we were both frustrated by a similar problem – but seen from a different view.

My friend told a story about how he had to travel on business and how he had found a hotel closer to his client’s offices so he wouldn’t need cab service. The problem was that the hotel was not part of his company’s preferred vendor list, and it was $10 more expensive than the hotel 30 minutes away that was preferred. His experience from previous trips showed that he spent $45 on cab fair, so the net savings would have still been $35. So far, so good. However, since the hotel was not a preferred vendor, his expense needed management approval. So he went to his manager, and yada, yada, yada – the CFO of his business unit had to sign the form before he could get his expenses approved, even with a $35 savings. My guess is that that the cost of all the management attention on this expense cost his company something close to $250. So much for the $35 savings – his little deviation from policy cost $215.Continue Reading

Developement Anti-patterns

Fear Driven Development – When developers are under time pressure, and are more concerned about their reputation than their code base. They tend to deliver half baked code with all kinds of smells – to get it out the door on time – without thinking of the consequences. When their bad practices are called out by others re-working their work product – they deflect responsibility, blame others, and exhibit all manner of personality defects. The core of it is this:

 

“Fear turns non-competent learners into incompetent blamers.”

Blame

In order to invert this anti-pattern, we need to remove fear of reputational loss. This is necessary for healthy collaboration and learning. This could be accomplished by destroying the reputation publicly no reputation, no fear. This could be destructive, or constructive – but it works fast. This could also be accomplished by exposing a value system that displaces the fear. This is a longer road, and a more positive, happy road – but it requires a tremendous amount of thought and preparation.

Date Driven Development – When developers are incented by schedule alone, you will get all manner of bad behavior. Incomplete features swept under the carpet. Taking technical shortcuts designed to get us into production, but requiring a complete rewrite in 2 releases. Developers in this practice often collaborate well, but never expose to management just what shortcuts or compromises are taken. Often, you are lucky to get through acceptance testing before the software turns into a smoldering heap. The core of this is a management problem:

 

“Schedule is more important than cost or quality.”

Schedule

In order to invert this anti-pattern, we need to understand the cost of the date in terms of re-work, and allow the management to make a different decision. They still could choose the date, knowing the cost – but you may actually get to do the re-write – instead of living with the steaming pile for 6 releases of hell.

Documentation Driven Development – When developers are responsible for documentation in a high ceremony, heavy software development life cycle, it often is the completion of documentation that is audited, rather than the code or the content. Developers forget that design is about making good decisions and choices and simply document the arbitrary compromises they made. The core of this anti-pattern is a world view:

 

“Process is more important than talent.”

Stack_of_documents

In order to invert this, an infusion of talent is required. Talent values talent. Making project managers with limited development skills into team leaders or middle management, or allowing your software development methodology to become infected with regulatory documentation requirements being the two likely initiators of this anti-pattern. Go hire some serious talent, and let them hire some more talent. Listen to those talented developers tell you how you can do good design first, then figure out how to document that design sufficiently to pass an audit.

Die-Hard Driven Development – When developers are isolated and allowed to work “un-supervised” for extended periods of time, without integrating features or concepts together. It is hard to predict the result when you finally take a look at what has been built, but you can bet there will be booby traps, explosions and lots and lots of cursing. Often this is a result of attempting too much parallelism in an attempt to go fast. Sometimes it is experienced when the developers are very familiar with the business domain so they feel entitled to “code ahead” of requirements. The core of this methodology is process dependency inversion:

 

“We’ll start coding, while you gather requirements, ‘cuz we know what they want anyway.”

Dieharddevc

The way to invert this is to implement two common agile practices: 1) code swarming – rather than having 1 developer completing an entire feature – pile a bunch of developers on the feature in close collaboration. 2) walking skeleton – if the requirements are still squishy, and development has excess capacity, have them build a thin implementation of some core features, rather than building “final” versions of those features. Using these practices – drives core design concepts and implementation practices through the team together, rather than having each developer follow their own path (yippee ki yay mutha-f…). You get a small number of consistent working features soon, rather than a crap-ton of half baked inconsistent features later.

Demo Driven Development – When the process includes frequent demos to customer, it is customary right before a demo to quick-fix a bunch of defects in a cheap way to appear to have made more progress than you have. While it is somewhat disingenuous, it is hard to resist sweeping a bunch of stuff under the rug to impress your customer. The problem is when your dev’s do that without your knowledge and incur unmeasured technical debt. The essence of this anti-pattern is represented in this statement:

Demo11

 

“We’ll keep polishing the turd, while you tell stories to the customer.”

Golden-turd-polish

One way to invert this anti-pattern is to implement peer code reviews. Having others review your code solves a number of problems – no programmer likes to look bad in front of an audience, even if it is their cube mate. It also helps good devs socialize better practices and new ideas.

One Size Fits All (Not!)

Often I have railed against the stupidity of management, when designing one size fits all “round hole” policies. It is the single most abused policy anti-pattern in my experience.

Policy Structure:
For the purpose of this discussion, any policy can be divided into three components:

 

  • Benefits (why I need a policy at all)
  • Means (How we will get the benefits)
  • Measures (How we will know the policy is working).

Policies are often not “free”, in that there is some cost to implementing the policy. Policies often have “side effects” that are changes not specified in the benefits. These side effects can be positive or negative. Usually, the side effects of policies appear as we have to adjust business processes and practices to comply with the policy. These adjustments are evidence of “square pegs”, or gaps in the policy that do not contemplate the essential complexities of the business model.

The old aphorism – “if the only tool you have is a hammer, then every problem starts to look like a nail” derives from this type of anti-pattern.Continue Reading

Enough (as a damping mechanism)

In a recent post, Esther Derby describes a tendency of organizations towards oscillating between centralized or decentralized controls – I thought it was a brilliant insight in that she exposed that at the extreme reaches of the pendulum in either direction, there are evidence of lower performance, but for different causes. I have experienced this myself, but really never thought up the food chain to where these decisions get made, only about the local effect, and my own efforts to locally mitigate said effects.

In the article, it is suggested that centralizing controls tends to squelch innovation and creativity, slowing down decision making and reducing ability to maximize opportunistic growth, while decentralizing controls can allow decreased visibility, subunit goals to trump larger organizational goals and decisions that do not align with the mission of the organization. Both of these extremes tend to lead to lower performance, and so in reation to the downside of one extreme, we tend to lurch towards the other extreme.

Esther went on toward the need for feedback loops which would allow managers/management to detect and react to the pendulum and adjust to reduce the periods of lower performance induced by the swing.

What Esther is describing is a damping mechanism, like a shock absorber in your car. The damping factor is based on a target range of motion, and the further out of range the motion, the greater the damping force. As I thought about this, what is needed is a conversation about enough (a definition of sufficiency will be required) centralization or decentralization, and perhaps some discipline on sticking close to the definition of enough. Enough is the target range of motion we want to contain any oscillation between enough decentralization to prevent the loss of performance from those causes, and enough centralization to prevent loss of performance on the other extreme.

So the questions that management must be required to ask is:

1) How much decentralization of control is sufficient to prevent the loss of innovation and creativity in our workflorce?

2) How much centralization of control is sufficient to prevent the abandoning of corporate strategic vision for more localized goals?

I also think that this is a matter of establishing policies, aligned with rational management incentives backed by meaningful measures. This is where management usually falls down from my experience. Here are some management anti-patterns that tend to interfere with this process:

1) No measurement process is established, therefore the policy must be written in absolutes.
2) Policy is written and implemented in a “one size fits all” paradigm, which fails to contemplate how the policy might be implemented differently in different contexts to achieve a similar net effect.
3) Incentives do not go far enough down or up the management hierarchy, so the desired behavioral changes are not properly incented at the point where they are necessary.
4) Incentives do not align with the policy, creating a paper tiger – a policy that has no teeth – one that is paid lip service, but limited effort is applied because there is no perceived benefit to behaving differently. Draw a correlation between policy and compensation and you will see behavioral change.

Once we have overcome the management anti-patterns, then and only then do the feedback loops become important – because the necessary constraints and enticements are in place to ensure appropriate action when the feedback is delivered.

Esther promised a future post about feedback loops, and I am keen to read it, because she is typically very insightful.

A Template That Inspires Innovation

After adopting a new design process philosophy, and implementing a trial project using it, a design anti-pattern has presented itself.

Document Driven Design – this anti-pattern is the practice of allowing whatever document template is mandated, drive the actual process or practice of design.

It is common in the enterprise space, especially post Sarbanes-Oxley where such documentation is as essential for passing regulatory audits as it is for constructing application systems. Sometimes enterprise management get confused as to which is the primary objective. While I haven't read the federal register to determine what actually is required, many organizations have followed the consulting firm model, and developed a documentation framework for software projects that is mandatory.

I would expect that organizations that are towards the higher end of the capability maturity model use templates that are reflective of their already mature process, but organizations that are more steeped in chaos may be tempted to produce document templates that are an amalgamation of several different processes, thinking that those responsible for authoring those documents will know how to complete them. I have seen that this is not the case, and it can cause the aforementioned anti-pattern, that is reflected in the following statement: Design is complete, when the document is done.

As I said, I realized this after trialing a new design philosophy. New philosophy has 5 steps – initiate, decide, articulate, analyze, review. Articulate is the step where the the first draft of formal design documentation is created. The team had done fairly well, following the requirements of the philosophy until this point, and when they got there, we tripped over the template. Boom! Instead of figuring out what needed to be articulated, we attempted to cram all of the decisions we had made into the existing template, and became confused and the result was frustration. We got to the review step, and questions and accusations were flying. I had a great deal if trouble figuring out what went wrong.

What was the problem? Template thinking trumps philosophy! Why? I suppose that this is an instance of transposition of the familiar.

Now I realize that I have a challenge – that to support our new design philosophy, I need to construct an "articulation template" that can inspire innovation and help the team with the remaining steps of analysis ( which in my philosophy is impact analysis) and review.