Saturday March 11, 2006

The value of apprenticeship

There are many eternal debates in software development, arguments that are never really settled, but that are always good for a philosophical discussion, or a yelling match: vi vs emacs, formal specifications vs extreme programming, low-level languages vs high-level languages. Some of them are rather silly, but some of them have very serious management implications. The one that really gets my blood boiling is whether new development should be separated from software maintenance. In other words, whether a product team should be split into a creative crew and a bug fix crew, usually with the bug fix crew safely isolated in another part of the building. 

The main argument for separating them is that the product team won't be able to ship new releases on time if they are constantly bogged down with fixing bugs in old versions. Piffle, I say. Nonsense! Software development is a craft. The way you learn a craft is by being apprenticed to a master, starting by doing the lowest tasks in the shop. You watch the master in action, ask him for advice, and, truth be told, learn from his mistakes without having to make them yourself.

This is not to take anything away from bug fixers. Bug fixing is an honorable activity. I have known bug fix crews headed by master developers who were very competent indeed. But I'd be willing to bet that those masters would have been a lot happier doing new development, and the organization would have been better off with their talents being put to use doing it.

Separating the teams has a bad effect on the new development crew, too. If you aren't confronted with the consequences of your mistakes, how are you going to learn to not repeat them?  Who among us isn't tempted to throw his doubtful efforts over the fence for the next guy to fix, if we can get away with it?

Yes, having the apprentices pester the masters for help in fixing bugs will take energy away from new development, and may cause the schedule to slip. But not as much as one might think, because the new development guys are going to have to port the fixes to the new version anyway. Why not give the apprentices the chance to work on the new version by doing those ports at the same time that they fix the old version? For an apprentice, there is nothing like the thrill of getting the chance to put her hands on the new release, whether it's a piece of software or the facade of a cathedral.

Finally, there is a real benefit, even for the master, in having the old version constantly in front of him as a model. I have seen losses of functionality from the old version to the new version more times than I care to remember. If you are constantly reinventing the wheel, you're going to get some lousy wheels.

So keep the crew together. If you care about quality, if you care about developing your people, both masters and apprentices, it's the only way.