Unhippyish Design

As we arc our way steadily across the adoption curve of Agile development we learn many lessons.

In the early days of Agile our naive optimism heralded a new golden age of software development where everybody had a stake in the solution. Gone were the days of the hallowed architect sat up in his clouds passing down edicts to the lowly bit-munchers. We no longer had to accept the crazy mumblings of some old fool prattling on about dependency management (these days this is me!). No, we all had a part to play and could say how things would be done.

We practiced Collective Ownership.

As mindless Agile mantras go, this one is my favourite. I can remember clearly the change in pressure that I felt when we started to share the burden of dubious design decisions.

This was not so much about blame. Having spent ten years at the sharp end of crazy Waterfall plans I was used to being blamed for the integration train smash that came at the end of most projects. The developers got it in the neck because they were the last in a long line of dubious decision makers. Those closest to the front, the project managers and the analysts, seemed whiter than white.

For me it was more about professionalism. The confidence that resulted from discussing alternate approaches with other like minded people felt good. Even then, I really enjoyed the activity of designing something with others. The joint responsibility was amazingly empowering having experienced the draconian siloing of the pre-XP world.

And it was incredibly powerful!

There are very few problems that can endure discussion among committed, skilful professionals.

Coupled with the reductive power of Test Driven Development and the mutual support of Pair Programming, Collective Ownership softened the lines between departments. We all shared the problem and we all shared the solution. This opened the door to the multi disciplinary work streams we see today that for me represent the gold standard of delivery.

However, in embracing Collective Ownership we made one fatal error. We threw away entirely the notion of design authority! In our eagerness to do away with the crazy mumbler we forgot one of the central tenets of software development.

Successful software projects have cohesive architectural vision.

Where once we had all bowed and scraped as we collected our Yourdan structure charts from the architect and headed back to the basement, now we sat around in pairs under the trees and drew patterns in the leaves. We rejected formal design methods as being too restrictive to our creative juices and preferred informal chats at the keyboard or at the whiteboard.

We had become hippies.

This was great because even the least experienced among us could have an input to the how the system evolved. Also since no single person had responsibility for the architecture, when the architecture that emerged from our collective musings turned out to be dazed and confused, there was no one to blame; because everyone was to blame.

And we protected this flattening of the design authority within teams and we called it empowerment. We quickly dispatched anyone who pretended to be in charge of the design or who expressed interest in the architectural shapes that were emerging that couldn't be seen in a unit test.

We had replaced the autocracy of the architect with the commune of joint design authority and, like most communes, we were headed for a crisis between leadership and the masses.

With hindsight I should have gone back to the crazy old mumbler and asked him to explain how dependency management limits cost of ownership and reduces churn. I should have asked him how to decommission systems safely and how to adopt 3rd party solutions without becoming inured of them; how to collaborate an architectural vision across 100 developers all working on the same code base; how to protect high business value parts of the code from changes in low value parts of the code. Because I'm pretty sure he knew!

But I didn't ask him.

I think it was because I was Agile and he wasn't. It was because Agile was new and in the software industry newness is paramount and what is old by definition must be wrong. He was wrong because he was old and followed a style of development that was definitely unhippyish. I bet he never hugged a tree in his life!

If you have flattened the design authority in your development team such that every individual has an equal voice in all aspects then you have seriously reduced the efficiency and safety of your development effort. This is particularly true on large programs of work where collaboration is enabled primarily, not through working practice, but through system architecture.

I have to tread carefully here because I am certainly not advocating we go back to the days of disempowerment. I remember not having a say in the design of a system that would be delivered late and it sucked!

What I am encouraging is that the degree of empowerment of an individual on a team should be proportional to that persons skills and experience.

This means, broadly speaking, if you have someone who has ten years proven track record, you should realise his advice in the code to a greater extent than a person who has only two years experience. I won't go as far as to say five times as much but you get my point.

In the Frisbee throwing world that software development has become this sounds like heresy but is it really that crazy? Would you walk into a hospital and demand to be operated on by a junior intern rather than the chief of medicine?

I didn't think so.

Why are we assuming that everyone has equal voice? Certainly everyone should have some voice but we should leverage the skills that we have and not pander to the least common denominator.

Of course it's a little more complicated than that. We all have differing levels of skill and experience in various aspects of software. The most important step in leveraging the skills on your team is knowing where they lie.

Conduct a skills audit.

Once you know who knows what then assign design authority for each area of concern to the person with the most experience and skill in that area. Give that person power and responsibility.

Each key aspects of the design should have strong ownership. This will ensure it is not allowed to drift in the gaps between feature development.

I would recommend that you assign one person to each area that you care about with the exception of the high level architecture which ought to be covered by two people in the interest of redundancy.

Above all ensure that the higher order architecture has clear leadership and vision.

Again I am not advocating total power. Software development is primarily an exercise in collaboration. These design authorities must listen to the opinions of all because even inexperienced people can have insight (though mostly they won't).  However, when it comes down to implementation those in the know should be the ones making the key decisions.

If you do this you will increase your chances of building a cohesive system that is driven by knowledgable leadership.