Software engineering is a term often used to encompass the entire range of software development, from creating high-level architectural designs to low-level coding. In Software Craftsmanship: The New Imperitive, Pete McBreen proposes a more strict definition of software engineering as the processes and methodologies appropriate for large scope projects involving many person-hours of development. However, most programmers don't work in teams of 500 writing military defense software. Instead, they work in small teams, often in close collaboration with the users of the software they create. McBreen offers a craftsmanship model in place of the more rigorous engineering methodology for these small teams of developers.
At the heart of the craftsmanship methaphor is the guild system of classifying programmers as apprentices, journeymen, and masters. A master programmer will lead a small hand-picked team of journeymen and apprentices, who work together on the simpler parts of the project. This frees the master to work on design and the most complex aspects of the project. The master does not work directly with the apprentices, but in observing their work he can correct mistakes in their approach by correcting the journeyman, who will in turn pass the lesson on to the apprentices. This approach focuses on successfully completing the project while allowing the apprentices and journeymen to learn along the way.
Another important aspect of craftsmanship is the relationship between the programming team and the users of the software that they create. Ideally, the customer selects the master crafstman for the project, and in turn the master selects the apprentices and journeymen to make up the rest of the team. The customer and the master work closely to ensure that the software will meet the customer's needs. Because of this relationship the customer can expect high-quality software from the programming team.
Also contained within the description of the craftsmanship model is some good general advice for anyone who develops software. One is the idea of perpetual learning, where all programmers on a team are constantly learning from each other. Not only will apprentices learn from journeymen and journeymen from masters, but masters will have the opportunity to learn from apprentices, who may have more recent exposure to new technologies. Another is that software applications should be built for ease of testing and maintenance. The measure of a successful application is its longevity, and in order for an application to achieve a long life it needs to be adaptable to changing customer requirements. A corollary to this principle is that maintenance programming should not be a dumping ground for inexperienced and less competent programmers. Passing an application to a group of maintenance programmers after an application has gone into production is more costly in the long run; the new programmers do not have the domain knowledge of the team of developers who created the program, which can lead to mistakes due to an insufficient understanding of the application.
Some of the proposed methodology may not prove feasible, however. Redefining developer roles in a feudal hierarchy would likely be extremely difficult to implement in an established shop. Lowering the pay of apprentices and journeymen to increase the pay for masters would likely also encounter strong opposition (although probably not from the master). Plus, there are few provisions for an incomplete team. What do you do if all you have on your team are apprentices with no budget to hire a master? What do you do if your master wears a Star Trek uniform to work and won't acknowledge anyone who can't speak Klingon? A partial implementation of such a strict hierarchy does not seem workable.
Those who work in traditional software engineering may not find much of interest in this book. However, the idea of software development as a craft will resonate with many programmers who work in small teams to create great software, and view their work as more art than science. Software Craftsmanship presents an alternative to the formal software engineering discipline for more typical development projects, and is well worth reading.