Software Craftsmanship: The New Imperative

by Pete McBreen and Mike Hendrickson

Book Overview

Software Craftsmanship is a call to arms for programmers: an impassioned manifesto that restores the developer to a central role in large-scale projects, and shows developers how to master the skills they need to succeed in that role. Software Craftsmanship transcends "software engineering," demonstrating that quality software can't simply be "manufactured" it must be built by craftspeople with pride in their work, and a personal...

• Format: Paperback
• Language: English
• ISBN: 0201733862
• ISBN13: 9780201733860
• Release Date: August 2001
• Publisher: Addison-Wesley Professional
• Length: 208 Pages
• Weight: 1.01 lbs.
• Dimensions: 0.5" x 7.4" x 9.1"

Customer Reviews

Software Craftsmanship: a worthy goal

I just spent this rainy afternoon reading "Software Craftsmanship ... The New Imperative" by Pete McBreen. The book's main theme is that the craft of software development has suffered from too much emphasis on the "horde approach" of software engineering, particularly on small teams. The Tayloristic perception of developers as common-denominator, replaceable resources is dismissed in favor of developers going through the apprentice - journeyman - master craftsman process. Such artifacts as certifications, licenses and diplomas are contrasted with the value of OJT in the right managerial environment. The stultifying affect of excessively detailed analysis and design at the beginning of a relatively small project is compared with a more iterative cycle of coded deliverables. The whole idea of specialization into analysts, designers, coders and testers is called into question for small projects.In fact, even the conceptualizing of software development as a project is discouraged. Better to realize that crafting an application is a never-ending process which may result in something which outlasts its own developers and development tools. Not that the developers should necessarily move on. McBreen encourages the notion that maintenance programming, far from being stigmatized as a menial task relegated to the novice programmer, should be a prestigious task given only to the best skilled, the best paid and the most experienced with the original development. It's not that everything in the book has never been said before. It draws on a rich bibliography including Fred Brooks and Edwards Deming. Its inspiration from "The Pragmatic Programmer" and eXtreme Programming are evident, but not overwhelming. I don't think I can give it a just review without quoting the whole book. If I had to choose one book as my software development manifesto, this would be it.

A MUST-READ for frustrated software developers

Ever wonder why all the talk of "software engineering" left you feeling cold, as if all your brain power, your creativity, your pride in your work, could be reduced to a mathmatical formula? I did. I wanted software engineering to be the answer, but the more I studied, and the more I experienced, the more I believed that software development was essentially a human activity, not an engineering activity. Pete McBreen's book, Software Craftsmanship, finally crystalized my thinking. I spent the entire book saying "Yes, I've been there, seen that, thought that, yes, yes, yes." Not only does McBreen clearly define the problem, he goes the critical next step -- which is to offer a solution. Software Craftsmanship offers a new model for thinking about software development, a model that fits in beautifully with the "agile" community, and gives a refreshing alternative to the "software engineering" community's insistence that software development will be reliable, repeatable, and produce excellent results as soon as we can eliminate humans and their messy judgement and flaws from the picture. Thank you, Pete McBreen, for giving my profession back to me.

Development managers READ THIS BOOK

I loved and hated this book. I loved the great job that Pete McBreen did of describing many of the intangible issues that arise during great software development efforts and the difference between a craftsman and a hired gun. He touches on issues such as evolutionary delivery and actually (gasp) meeting with the customers, that make the difference between a delivered application and a real, working, solution to a users needs.I hated the book because I'm afraid that I'll never work for a manager that has actually read it, and appreciates all that's being said. I'm really tired of seeing the same basic mistakes (covered in the book) being made over and over again. -- No need to test, we'll do that in the field. -- Here's the delivery date and the needed functional list, you engineers code like crazy (literally) and get it done.Development managers, this is not a difficult read. Do yourself, and your team, a favor. Buy and read this book. Then re-read it every 3-6 months or so, so you can tell if you've actually adopted any of the ideas.Hey Pete, are you hiring at present?

The Programmer as Artisan, not Engineer

This is the book for those of us who've read all the standard works on classical software engineering methods and can't lose the suspicion that they're WRONG. Software Craftsmanship: The New Imperative revealed the one important fact about how software engineering was derived from giant government projects in the 60's and 70's that I didn't know: those projects included building the hardware on which the applications would eventually run. The reason for the emphasis on long, detailed requirements and design documentation is that this was the best use of the dead time software engineers had while the machine and its compilers were being constructed. As soon as the box was ready an army of coders was given the detailed design documents and converted them page-by-page into source code. Programmers who have ever wondered why they were being paid high salaries and then treated as mindless drones now have an historical explanation. Pete McBreen isn't the first person to question standard procedures for developing commercial software. The Open Source movement has proven that high quality, useful software can come from developers using no specification documentation at all. The eXtreme and Agile methodologies have shown it is acceptable for specifications to change during the course of the project: Customers will be more pleased with the final product if they can revise their requirements as they see the product developing.So who could possibly be holding on to a methodology that is demonstrably inappropriate for modern small software groups developing commercial products? Mr. McBreen fingers managers whose pay and prestige depend upon head count. Turning every project into a relay race with analysts, designers, programmers and testers guarantees many billable hours while intellectual property is passed on from group to group. Preferentially hiring young, inexperienced programmers and capping the salary rate ensures a bloated staff with high care and feeding needs. It's a provocative assertion that will certainly engender debate.McBreen says he wants to join in the public conversation that already includes the voices of Richard Stallman, Linux Torvalds and Kent Beck. His intelligent analysis of the origins of classical software engineering and why it is no longer a good paradigm for commercial software development will help keep that conversation informed and productive, as well as lively.* Books mentioned by Mr. McBreen include:The Pragmatic Programmer by Andrew Hunt and David Thomas ISBN: 020161622XThe Inmates are Running the Asylum by Alan Cooper ISBN: 0672316498

Approaching Programming as a Craft

For a long time, computer programming has seemed to me to be more akin to writing a symphony or a novel than constructing a bridge, despite the fact that the industry has tried to make it like bridge-building by treating programming as "software engineering" and trying to use engineering methodologies to control development. Pete McBreen's book goes a long way toward explaining some of the software development phenomena we see, and why so much software engineering practice doesn't seem to work. I've written test tools for lower-level software, and I've noticed that the usual engineering methodologies do not explain what I've seen -- some people's code is simply better than others with fewer bugs (this variation in programmers has been known for a very long time), and I'm not sure how fundamental improvement can be legislated in a programming department or by the government. The conventional wisdom does not come to address one fact: one of the most important factors in the quality of software is who is writing it. McBreen acknowledges this and suggests a road by which more programmers can excel -- he believes such "stars" can be made. And it's interesting how he ties in the present trends in Extreme Programming and the Open Source development community, as well as the old Chief Programmer Team model, to bolster his thesis. McBreen presents an apprenticeship model for the development of programmers that actually has been done at times and places, although much less formally. My first programming job was something similar to this and stands in strong contrast to the world today where a new hire from college has a "software engineer" title and thrown into the deep end of the pool. I imagine many new graduates from MIT or Berkeley would be insulted at the idea of taking a job with a title "Programmer Trainee". Some of us have done just that. This book is a great read, and, as with so many good books, it's too short. He presents the craftmanship model but the book cries out for more explanation on implementation and what has happened when it is implemented. Many of us cannot implement company-wide changes ourselves, however, we can see programming in a new light and possibly begin change, in our own work, how it's approached and written.