A Chain Without Links?

Serial circuitry is simple but very fragile, a failing link causes the entire circuit to fail.

A serial circuit operators life is made that much more difficult by the added maintenance burden this imposes – of having to check each component to ensure the circuit does not fail. Essentially it’s a dumb circuit that requires constant management. An operators time is quickly consumed managing the circuit.
What if the circuit components had added intelligence allowing them to diagnose their condition? The simple circuit model is still in-tact, each component relying on the others, but the operators life is made that much easier.

This theory is no stranger to the automobile industry. For decades they have provided facilities for vehicles to self-diagnose problems in all aspects of vehicles, from engines to tyre pressure.

Why hasn’t this theory been applied to software? How much easier would administrators lives be with self-diagnosing software, applications that can express their condition through a convenient interface? I’ll make some analogies between the software and automobile industries to highlight how we’ve dropped the ball:

• Applications are diagnosed by simply starting the engine and seeing what happens.
• Applications are typically more complex in nature than automobiles. Interestingly though application administrators are usually as ignorant as automobile operators when it comes to inner workings.

This is an intriguing topic. Why haven’t tools surfaced that more easily provide this capability to applications than via custom development? Perhaps software is less prone to failure than vehicles? As intriguing as it is, I digress from the main point of this entry.

The basic theory behind the chain and link analogy is that each link knows itself best. Each is best at informing the other links of its condition and its connecting points (interfaces). It’s classic OO theory – data is held, managed and encapsulated by each link to form the chain.

10 years ago Brooks made reference to this principle in the context of management styles – he titled his section on this topic as The Power of Giving up Power. The theory was that management should delegate as much as possible to its subordinates. He highlighted the net result is increased morale, freedom, creativity, productivity and a greater capability of management to manage the whole operations as it’s less concerned about the inner workings of its parts. Indeed, management has more power in managing the organization as a result. I couldn’t agree more. It’s a very generic, simple theory that applies to life in many ways.

For software project management, I see these subordinates as groups of analysts, developers and testers. Each of these groups knows best how to efficiently integrate with the others. Why not trust in their knowledge? Rely on them to integrate with the other groups in a way which best suites them. Let them tune their practices in-line with the overall methodology in a way that’s best for them. Give others the opportunity to advise and negotiate especially on the touching points with other groups, but never dictate. That is a sure recipe for disaster leading to probable inefficiencies, distrust and disenfranchisement. Management should clear it’s vision of ‘this group should do A, B and C to produce X, Y and Z’. Instead management should be concerned about articulating what needs to be produced and leaving the groups to decide how best to produce it. Let them hopefully reap the benefits Brooks mentioned as a result. This principle should be the guiding principle when formalizing any methodology.

And if you’re inclined to dictate to a link because it is not smart enough to know, then perhaps that link needs an upgrade – they may lack the experience needed to do their job well.