It should be obvious why working in a team is good. Things like when you start measuring the amount of work in an interesting project you come up with a figure in man-years, that tells you that you might need a little help on this one. Of course, there are instances – mostly back in the grand old days of personal computer and minicomputer development – where wonderful things were made by one or two developers. Like the ‘C’ language compiler, the Altair BASIC compiler, VisiCalc and so on.
So why shouldn’t we all develop that way? Well, those people who developed those things were incredibile geniuses whose passion and ambition for developing unbelieveably good software was matched only by their skill at actually doing it. They had incredibly deep and broad knowledge that went all the way down to the hardware, and now, with applications involving graphics, the web, databases, messaging middleware etc etc, body of knowledge is now so vast that it is hard to imagine one person knowing it all in depth and keeping it current. You’ll also notice that the list of one-person miracles is rather short. No doubt there will millions of young keen developers out there writing language compilers and dBase variants and most of them are long gone; most of them never even compiled. Have you ever browsed around at sourceforge and seen the huge number of projects that have never produced a single working version of their product or even checked in anything that compiles? That is the normal fate of the work of the lone developer, oblivion.
When we allow lone developers to work for a long period of time in a company the result is almost as bad. Eventually we will want to integrate the efforts of all these lone developers. When we do we end up with a system that is only as good as the worst developer. In terms of stability, maintainability and usability having each new developers learn lessons in their own time rather than being taught by an expert is a waste of time and money.
With a small amount of review or pair-programming we can spread our knowledge into the team in such a way that the less-expert developers learn from the more experts ones and everyone ends up getting a little better at only a small cost in extra work. Also, the system that results is as good as the best developer. The sad truth is that there is only one way to really learn the hard bits of programming, and that is by doing hard things. The hard things might be super-high performance, it might be backwards compatibility, it might be working with 25 year old legacy code or it might be, for the business programmer, coping with code complexity and being under pressure to do things as fast as possible. With the latter case, we have all kinds of books and patterns and practices, but you’ll never understand patterns by looking at example code; you have to look at things like 20,000 line classes or enterprise applications with 200 different screens or databases with 600 stored procedures and 400 tables. You have to look at code that has years of complexity hammered into every line. You have to look at code that has been written by people who have never told themselves no more hacks.