Collaborative Software Development

Ask some people to describe a stereotypical Software Developer, and you might hear something like, ‘a person locked in a dark room coding till the small hours in isolation, who then eventually emerges with a software solution to a problem’.

This may have been the case many years ago, certainly if you look at how many games were designed back in the 80’s for Atari and C64 etc, it does seem like one person was largely responsible for producing a software title, many of which bare the name of 1 or 2 developers.

I think it safe to say that this is no longer the case in modern software development, or at least it shouldn’t be the case. Software Development is (and should be) a collaborative activity. For a start, many problems to be solved today are large and complex. The best software is going to come from dedicated teams, sharing ideas, thoughts and designs, even pair programming. All this helps create a more rounded and well thought-out product.

This is an example of the phrase, 2 heads are better than one, and while this is true, what’s even better is 2 different heads are much better than 2. The point I am driving at is ‘Cognitive Diversity’. The post is inspired by a recent conversation with a friend (showing the power of conversation) who reminded my of the great book ‘Rebel Idea’s’ by Matthew Syed. I had been meaning to write this post for a while, but it slipped my mind, so this was a timely reminder for me.

Matthew’s excellent book discusses the important of cognitive diversity when looking for solutions to problems. I am going to look at this in the context of software development, and in particular design.

Collaborative Design

First of all in my view, design is a vitally important part of software engineering. I have heard conversations like ‘It’s Agile, no need for design’ – For me that doesn’t cut it. Agile does not say this, what is says is working software over comprehensive documentation. Design is part of the process of creating working software, if you want maintainable software that will last for years to come.

Design is part of the process of creating working software

What we need to do the right amount of design at the right time. We don’t want a big detailed upfront design, trying to cover every single small detail and taking many weeks to complete. This doesn’t allow for creativity or an easy change of direction. On the flip slide, we don’t want no design, what we really want is a sensible balance. A reasonable amount of design to fit the problem to act as a starting point for exploration and conversation. This provides valuable documentation detailing the why.

This still allows for proof of concepts, as these can provide valuable information feeding into a design. High level design, a design on a page, or maybe just a whiteboard session, these activities allows exploration at one of the cheapest stages of the software development cycle. However, to gain the most from this design, you need collaboration.

When producing a design together, or at the very least circulating the design for feedback, you cover much more of the problem domain and stand a far better chance of getting a great product out the other end and uncovering potential nasty issues as early as possible.

The Problem Domain

Using the analogy from the book Rebel Idea’s, lets represent a new requirement or user story as a rectangle.

Now if just one person (illustrated below as a developer) analyses or works on the problem in isolation, they can only cover so much of the domain. This will of course vary depending on the size of the problem, complexity and their experience, but the point is we don’t know what we don’t know, so it might be some areas are just not highlighted because that person is unaware of them.

We don’t know what we don’t know

Increase Problem Coverage

Adding another person will increase the amount of the problem covered, as each individual have different experiences and knowledge, ensuring more of the problem domain is covered. But (and this is the point of the book), if the other person has very similar experiences and knowledge then there is a large portion of over-lapping.

Cognitive Diversity

To gain more ‘coverage’ you need people with more diversity in their thinking – cognitive diversity. So, in our software development context, gathering input and sharing designs with Operations, Support, Test, Product Owner etc will almost guarantee cognitive diversity, as each will bring a very different perspective on the problem.

Summary

• Software Engineering is achieved through teamwork
• Sharing and discussion of a design can save a lot of time later
• Share early, share often – You don’t know what you don’t know
• It’s good to talk!

Credits

This post was inspired by the book…

Rebel Idea’s by Matthew Syed