Developing software is all about moving ideas and knowledge between minds. It’s beautiful and scary because software is just that – ideas manifested into semi-existence in the form of electrical signals in a machine.
Knowledge is the key here. We need many different types of knowing to build systems. We need to digest the thousands of hours of effort that has been put into thinking up the programming language that we’ve chosen to use. We essentially move some of the platform designers’ ideas into our heads, and armed with this knowledge, we create. We need to understand their mental models – if we don’t, we can’t use the tools that they have created.
Encoded in the code libraries you use are hundred of hours of hard thinking by the makers. The better you understand the models that the library makers used when they created their software, the better you can use it.
You need to move the knowledge from the domain experts’ minds into your own to be able to create useful software. Sometimes the domain expert is a book – the idea still stands. Someone spent a lot of time writing down their ideas, and now you have to move their ideas to your head.
Anytime a group of people work together, you need to communicate and understand each other to be able to co-operate. You will learn about each other – what makes you tick, what your team mates are good and not so good at. To work together effectively, understanding of each other is crucial. You have probably heard stories about couples that have been together for many years, and how they barely need to talk to understand each other. They just have learned to communicate extremely well with each other.
Lastly, when we write the actual code, we’re codifying our ideas into a form that can then produce runnable bits. The code will probably be read over and over again. Either by a future you that has forgotten the details you know right now, or to someone else. We still need to move ideas between minds.
In all stages of our work, be it analysis, design, coding, testing, this basic premise holds true. Learning – moving ideas and knowledge between individuals – is such an integral part of developing software that people forget about it. We sometimes think that the solution is already there, that the only thing stopping us is how fast we can type. Theory of Constraints, the management philosophy by mr Goldratt, claims that a system will always have at least one constraint. This constraint is what limits the systems total capacity. The system can’t produce more than this limit. So finding the constraint, and working on increasing it’s capacity is key to optimise a system.
Our industry’s common constraint is this transferral of knowledge – learning. Everything we do that helps us do learn faster will improve our effectiveness, and everything that diminishes our learning capacity will directly affect our productivity. Sitting close to each other opens up the possibility to use effective communication channels. It allows us to boost all the learning that is an crucial part of developing software.
Do I think that software can successfully be developed even by teams not sitting side by side? Of course it can. There are thousands of examples where distributed teams have produced high quality software that solved the business’ problem. I use Linux daily, and I don’t think Linus is sitting next to all the kernel committers.
What I tried, but failed, to say in my last blog post is that it’s so much better to work close to each other, that you should have very strong reasons to do anything else. Open source development done on by dispersed people on their free time is one such reason. Unavailability of developers at the right level might be another reason. Just take into account that the difference is not just a few percent less effective. I’ve seen teams productivity increase by more than 300% just by having the domain expert sit in the room with them for one week. You might want to give that productivity boost away, but make absolutely sure that you know what you are doing when you decide to split up your team.
Distributed development forces you to do better documentation and written down knowledge transfer. This may pay off over time.
Left by beza1e1 on October 24th, 2008
Beza1e1:
Yes, documentation might pay off over time. But it might also not. I claim that sitting together will almost always increase productivity. Do you think that documenting better will make a team 300% more effective?
Left by Andres on October 24th, 2008
Andres, you might want to consider this description of highly effective distributed development: http://blog.xebia.com/2008/08/21/agile2008-fully-distributed-scrum/
What Jeff and Guido were saying at Agile 2008 was that using the right approach distributed development works so well that you’d be a fool not to do it (given the lower cost and higher availability of off–shore developers) In fact, Jeff pretty much recommends that you look for opportunities to do that. He says “fully distributed Scrum has more value than localised Scrum”
Here’s the difference that I see: you have a compelling theoretical argument that contradicts Jeff’s claims about his actual experience. Something has to give.
Left by Keith Braithwaite on October 26th, 2008
About documentation, hasn’t it been established that most documentation is never read? I would say that the one thing that is better than producing a good piece of documentation is to remove the need for that documentation.
I have no deep insights regarding distributed development, but a simple reflection is that if the people that for one reason or another (cost, skills, …) are the most suitable to develop something are distributed over the world, then distributed development should make sense. After all, it’s not impossible.
Left by Jesper Larsson on October 27th, 2008
Keith:
Of course it’s not a black and white thing. I’m absolutely certain that their are a number of situations where distributed development makes very good business sense. I’m not trying to say that there aren’t. Maybe “you’d be a fool not to do it” is a bit to strong for me. I think that many people agree with me that software development is hard enough for most companies without the added problems introduced by distributed teams.
I know nothing of Jeff’s experience. Haven’t read any detailed experience reports about it. My own experience points to something else, and I won’t give up that thought just because of a presentation held at Agile 2008.
Left by Andres on October 28th, 2008
Keith,
Here is a concrete experience at odds with Jeff and Guido.
http://blog.jayfields.com/2008/09/is-distributed-development-viable.html
Where does that leave us?
p.s. Hi Andres
Left by Jeff Santini on October 30th, 2008
Keith:
I read a paper written by Jeff Sutherland et al. http://jeffsutherland.com/scrum/SutherlandDistributedScrumHICSS2007FinalSubmission.pdf
What I get out from it is that you have to see distributed development as a big investment that takes at least a year to get going, and takes considerable amount of work to get to work, and even then, the pay off is not even close to the wage difference.
If you have time, energy and money to invest, and you are already very good at developing software effectively, distributed development might make sense.
Most of the teams I’ve met that want to use distributed development are already struggling with their communication today. Introducing the problems of distributed development there wouldn’t make sense. That is the gist of what I was trying to say. Your mileage might vary.
Left by Andres on October 30th, 2008
Andres,
I think it has all and everything to do with the project goal, size and structure. I have never worked in a big corporate distributed project, but I am working in both a (very) small corporate project, and a mid-size open source project, and they are both doing very good.
Actually, I’ve come to think that ‘respect’ is a key factor. You really have to think that your peers are cool people with the cool ideas, that you like (or at least accept) on a personal level. If so, talking to people, sharing ideas and knowledge becomes an act of love.
Actually, maybe ‘love’ is a better word. Love for your peers, love for the project, love for the work and love for the code.
Yeah. Love.
Left by Stefan Andersson on November 17th, 2008
@Stefan: You hippie!
Left by Marcus Widerberg on November 24th, 2008