Collaborative design

Let's imagine that you've been tasked with building a 3-tier web application and you have a small team that includes people with specialisms in web technology, server-side programming and databases. From a resourcing point of view this is excellent because, together, you have experience across the entire stack. You shouldn't have any problems, right?

The effectiveness of the overall team comes down to a number of factors that include people's willingness to leave their egos at the door and focus on delivering the best solution given the context. Sometimes, though, individual specialisms can work against a team; simply through a lack of team-based experience or because ego gets in the way of the common goal. Ask the specialists in the team where a certain feature or component should go and you might get 3 totally different answers...

• [Web developer] Just give me the data and we can do anything we want with it on the web-tier. We can even throw in some JQuery to dynamically manipulate the dataset in the browser.
• [Server-side developer] We should reuse some of the existing SQL queries in the middle-tier service layer and enrich the data in the middle-tier. This increases reuse, is more secure than sending all of the data to the web-tier and, besides, we can write automated unit tests around it all.
• [Database developer] You have to be kidding, it's way more efficient to write a stored procedure to provide you with the data that you need.

Our own knowledge, experience and preferences tend to influence how we design software, particularly if it's being done as a solo activity. And in the absence of communication, we tend to make assumptions about where components will sit and how features will work. And you know what they say about assumptions being the mother of all...

One of the key reasons I use low-tech kit to design software is because it encourages a more collaborative approach to the whole design process.

A whiteboard allows for much more collaboration than somebody sitting on their own in front of their favourite modelling tool. And you know those assumptions people typically make about how the software is going to work? Some of them can lead to software that is inconsistent and unclear. Getting those assumptions out into the open as early as possible really can help you avoid some nasty surprises when it's too late.

Like pair programming, collaborating is an effective way to approach the software design process, particularly if it's done in a lightweight way. Collaborating increases quality plus it allows us to discuss and challenge some of the common assumptions that we make based our own knowledge, experience and preferences. Everybody on the team will have different ideas, and those different ideas need to meet.