Software Craftsmanship
Today’s software development projects are often based on the traditional software engineering model, which was created to develop large-scale defense projects. Projects that use this antiquated industrial model tend to take longer, promise more, and deliver less.
As the demand for software has exploded, the software engineering establishment has attempted to adapt to the changing times with short training programs that teach the syntax of coding languages. But writing code is no longer the hard part of development; the hard part is figuring out what to write. This kind of know-how demands a skilled craftsman, not someone who knows only how to pass a certification course.
Software Craftsmanship presents an alternative—a craft model that focuses on the people involved in commercial software development. This book illustrates that it is imperative to turn from the technology-for-its-own-sake model to one that is grounded in delivering value to customers. The author, Pete McBreen, presents a method to nurture mastery in the programmer, develop creative collaboration in small developer teams, and enhance communications with the customer. The end result—skilled developers who can create, extend, and enhance robust applications.
This book addresses the following topics, among others:
- Managing software craftsmen
- Understanding customer requirements
- Identifying when a project may go off track
- Designing goals for application development
- Selecting software craftsmen for a particular project
Software Craftsmanship is written for programmers who want to become exceptional at their craft and for the project manager who wants to hire them.
Review By: Eve Wallin
06/28/2010In this book, Pete McBreen describes a method of reliable software development that encourages teamwork and communication between everyone involved in a project, and recommends an approach different from the ‘scientific method’ which is the norm for most development lifecycles.
This book suggests a hands-on management style with a focus on quality, not quantity. The author encourages a process that does not end with delivery, but continues through the maintenance of a project. The success of this process relies on the 'buy-in' of everyone involved. As the author notes, this is a method that foregoes the usual vast numbers of team members who are isolated based on their expertise (developer, tester, quality assurance, etc.). Instead, the members are fewer, very successful, and well compensated because of their skilled work and reliability. Team members are selected based on past successes and are people who can be relied on to not only develop the software, but to communicate with the users and be able to select, train, and involve other members of the project.
With this method, new developers do not get a 'crash course' in the language or hardware employed by the project. Instead, they are brought in as 'journeymen.' They are involved as soon as they are selected, not isolated by being thrown into a piece of a project without understanding their role. As the new developers become more successful, they continue their involvement by becoming the ‘craftsmen.'
While I agree with the concept of the book, I am somewhat hesitant to agree that the craftsman approach will be immediately accepted. It may be a little too idealistic for some to start a project with users who have no concept of a product lifecycle. As the author points out, in the past, projects have implemented the scientific method of development. Craftsmanship implies communication and refinement of experience of all members of the project.
I found the book to be readable and interesting. Craftsmanship has until now, been dedicated to arts, rather than science, but McBreen proposes a valuable concept for product and process improvement. I definitely agree that communication and involvement of all members of a project is tantamount to the success of a software/hardware project. Project management is not an isolated group of people who serve as a liaison between developers and users, involvement in the entire project makes everyone on the team more aware of the process and a larger part of its success.