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.

This topic has dwelled in my mind since my ThoughtWorks days.

How does a developer win the trust of colleagues in highly skilled teams? How does one qualify to contribute to the select group that seem to form the conceptual architecture and high-level design? Or even the low-level design?

From my experience, highly skilled working environments, with officially relatively flat organizational hierarchies - still subtly form a hierarchy. To earn respect you have to win respect. Fair enough to some degree, but still the lack of officiality is more likely to lead to emotionally charged decisions.

In XP practicing organizations, according to Beck (in true emergent fashion), every developer should perform a little architecture and design every day. Granted this should never be solo, unless you happen to be on a one man ‘team’. But, what do you do if there is a select, implicit, group governing the design. They may not be control freaks, they just see danger in granting developers too much freedom. Now, in an organization that lives by Becks model, having this implicit design group is a slur on the other developers, albeit intentionally or not. It’s a clear sign of a lack of trust.

I can understand the reasons for such groups being formed - it’s a way of reducing risk. There’s a confidence that the group will make the right decisions. But if you’re outside that group, and you want to be a part of making the decisions (just like Beck preaches), then, depending on how seriously you take your profession, it can hurt. It limits your technical/professional progression. It serves to alienate colleagues. Though the intentions are good in the outer it’s considered badness.

But it’s not all that bad. The days of the Whiteboard Architect aristocracy that Brooks pictured all those years ago are thankfully going the way of the Dodo. Yet I think we’re struggling to reach Becks vision. Perhaps there’s two barriers holding us back:

• A general lack of skill in the industry.
• Those considered highly skilled seem to have superiority complexes.

The pride and confidence of the highly skilled make it especially difficult to break into the upper escelon of the ‘technical heap’. Maybe one day the serfs will subtilely rebel.

Which is the lesser of the two evil barriers? You tell me. From where I stand one is just as evil as the other.

I’ve been pondering the content of this blog for some-time now. As always, just like my code, if I’d have written this a month ago it would be entirely different. Here goes….

In my relatively short time in IT consulting and contracting, I’ve been fortunate enough to work on teams with members having strong technical opinions. I’ve also been unfortunate enough to work on teams where members are relatively without opinion – they are usually more focused on delivering business value. I find that one usually trades itself for the other.

It’s extremely rare to encounter a team member that has heaps of technical opinions. From my experience, both cherish and be wary of them. It’s difficult to judge the point at which serial ‘opinionators’ have more distracted the team from delivering functionality than benefited them by passing on words of wisdom. Like the boy that cried wolf, these people can initially appear important but later prove more of a distraction. Then again, if there opinion leads to an increase in efficiency, there contribution can pay for itself – so it’s tough to gauge if the pain will be worth it.

For those of you out there that are opinionators (I should mention that I’m only considering people with a RELEVANT & VALUABLE opinion) I’m not suggesting you’ve got problems, nor should you reign in your expressiveness. Far from it, I love seeing you all do what comes naturally and promote healthy discussion. I will suggest one thing though – that your colleagues need to know how to contain you. Closure communication patterns, such as ‘Digression’, ‘Offline Discussion’, ‘Email it to Me’ or perhaps even ‘Write a Book’ can effectively circumvent seemingly perpetual conversation, although I try to avoid ‘Talk to the Hand’ at the risk of burning bridges. Sustained communication patterns, such as ‘Yes, However’, ‘So that Means’ and ‘What do You Mean’ should be occasionally used with caution, especially when a team member is on the ‘really’ critical path.

All jokes aside, establishing team protocol to the circumvent less than pressing discussion can help make everyone feel productive, especially in meetings with many attendees.

A final point, for those of you like me that tend to reserve their opinion. A wise lad once told me, regardless of your environment, being honest in expressing and arguing your opinion can only help you re-enforce, grow or question your own opinion through debate. It also helps those around you further understand you and possibly learn. It’s a situation that benefits everyone.

Happy communicating!