What do you think?
Rate this book
Software Craftsmanship: The New Imperative
Software Craftsmanship is a call to arms for 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 commitment to excellence. In Software Craftsmanship , Pete McBreen focuses on the craft of software development, explaining why current "software engineering" techniques often fail, and offering programmers a new path to excellence. Just as the modern carpenter benefits from better tools, materials, and understanding, the modern programmer can benefit from better computers, reusable components, and more robust languages -- but only if he or she is prepared to treat the software profession as a true "craft." McBreen explains what software "craftsmanship" means, how its affects users, and how it changes the developer's relationship with customers. He introduces the concepts of software apprentices and journeymen, shows what can (and can't) be learned from the software engineering movement, and presents specific steps you can take now to move towards craftsmanship in your work -- and your organization.
182 pages, Paperback
First published September 2, 2001
10 people are currently reading
799 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 24 of 24 reviews
July 7, 2011
Software Craftsmanship is an interesting book. It is extremely opinionated, but also rather inspirational.
The book takes a while to argue that the traditional model of Software Engineering is a terrible way to develop commercial applications, as it is really intended for enormous-scale applications and government work, like space shuttle software. The phrase "Software Engineering" today has come to encompass a much larger and much broader set of principles, but once I understood how the author meant it, I could easily see his point.
McBreen argues that an alternative view of software development, Software Craftsmanship, should be adopted instead. In the author's view, this is not simply a name to be thrown around lightly, he actually means craftsmanship. He argues that software developers should be grouped into Apprentices, Journeymen, and Master Craftsmen. Apprentices and Journeymen should work under Masters, and the movement between titles should be formal, not automatic.
He argues that craftsmen should expect to work together for 10 years or so on projects, and that Masters should never leave a project until they have hired and trained their successor. Pretty extreme stuff, but he makes his arguments convincingly.
He provides advice for how to properly start a project, train team members, maintain projects, and organize work, all within the context of the Craftsmanship model. He often compares Programming to Blacksmithing, arguing that the analogy to mechanical engineering is a poor one. Craftsmen should take pride in their work, and their names should be very visible within the applications they develop.
McBreen's suggestions are interesting, though many of his views come off as extreme. I agree with most of it while recognizing that adoption within the industry is likely to be low. The author also often comes across as needlessly cranky, particularly when he explains that using Java is "hazardous to your project's health", largely on the grounds that there is no open community around it (a criticism that couldn't be more wrong, as Java's ecosystem is one of the strongest within the Open Source world).
The book also tends to come off as a tad self-serving. One chapter is devoted to explaining that the intro salaries for young developers ($50-$60k) is far too high, and true craftsmen should be paid more around $250k. Speaking as a developer who would obviously love to get paid a quarter of a million dollars annually, software developers, even great ones, get paid more than enough money as is. Compared to other jobs, software development has it easy, so whining about how young developers get paid too much and master developers such as the author don't get paid enough comes off as ridiculous.
Overall, I like McBreen's general attitude toward professionalism in software, but a lot of his views could be categorized as fringe. An equally strongly-worded, but vastly more pragmatic book is Bob Martin's "The Clean Coder" which has a very similar point but much more agreeable (and when Uncle Bob is the less cranky of two people, you know the other guy is pretty damn cranky). I'd recommend both books to any developer who has moved past The Pragmatic Programmer and wants to continue to up his or her game, but if you can only read one book, read The Clean Coder over this.
The book takes a while to argue that the traditional model of Software Engineering is a terrible way to develop commercial applications, as it is really intended for enormous-scale applications and government work, like space shuttle software. The phrase "Software Engineering" today has come to encompass a much larger and much broader set of principles, but once I understood how the author meant it, I could easily see his point.
McBreen argues that an alternative view of software development, Software Craftsmanship, should be adopted instead. In the author's view, this is not simply a name to be thrown around lightly, he actually means craftsmanship. He argues that software developers should be grouped into Apprentices, Journeymen, and Master Craftsmen. Apprentices and Journeymen should work under Masters, and the movement between titles should be formal, not automatic.
He argues that craftsmen should expect to work together for 10 years or so on projects, and that Masters should never leave a project until they have hired and trained their successor. Pretty extreme stuff, but he makes his arguments convincingly.
He provides advice for how to properly start a project, train team members, maintain projects, and organize work, all within the context of the Craftsmanship model. He often compares Programming to Blacksmithing, arguing that the analogy to mechanical engineering is a poor one. Craftsmen should take pride in their work, and their names should be very visible within the applications they develop.
McBreen's suggestions are interesting, though many of his views come off as extreme. I agree with most of it while recognizing that adoption within the industry is likely to be low. The author also often comes across as needlessly cranky, particularly when he explains that using Java is "hazardous to your project's health", largely on the grounds that there is no open community around it (a criticism that couldn't be more wrong, as Java's ecosystem is one of the strongest within the Open Source world).
The book also tends to come off as a tad self-serving. One chapter is devoted to explaining that the intro salaries for young developers ($50-$60k) is far too high, and true craftsmen should be paid more around $250k. Speaking as a developer who would obviously love to get paid a quarter of a million dollars annually, software developers, even great ones, get paid more than enough money as is. Compared to other jobs, software development has it easy, so whining about how young developers get paid too much and master developers such as the author don't get paid enough comes off as ridiculous.
Overall, I like McBreen's general attitude toward professionalism in software, but a lot of his views could be categorized as fringe. An equally strongly-worded, but vastly more pragmatic book is Bob Martin's "The Clean Coder" which has a very similar point but much more agreeable (and when Uncle Bob is the less cranky of two people, you know the other guy is pretty damn cranky). I'd recommend both books to any developer who has moved past The Pragmatic Programmer and wants to continue to up his or her game, but if you can only read one book, read The Clean Coder over this.
January 6, 2013
This was an incredibly hard read. The book is so boring repetitive with its mantra: Software Craftsman good - Software Engineer bad.
Most of the good parts are quotations (like from the Agile Manifesto or from The Mythical Man Month).
The author's own parts are shallow (about maintainability, testing, best practices; since True Software Craftsmen do the good practices already anyway)
or contradictory (e.g. to maintain design for flexibility up-front plus do simple designs)
or plain wrong (e.g. to retain or attract great developers you just have to pay them enough, like 150-250k/year).
And that Software Craftsmen are better because their reputation is on stake is a ridiculous and unproven claim. They won't do anything against their customers' will (like working longer on the software because their honor requires perfection).
I'd rather recommend reading the books which are referenced (e.g. Agile Manifesto, The Mythical Man Month, Code Complete)
Most of the good parts are quotations (like from the Agile Manifesto or from The Mythical Man Month).
The author's own parts are shallow (about maintainability, testing, best practices; since True Software Craftsmen do the good practices already anyway)
or contradictory (e.g. to maintain design for flexibility up-front plus do simple designs)
or plain wrong (e.g. to retain or attract great developers you just have to pay them enough, like 150-250k/year).
And that Software Craftsmen are better because their reputation is on stake is a ridiculous and unproven claim. They won't do anything against their customers' will (like working longer on the software because their honor requires perfection).
I'd rather recommend reading the books which are referenced (e.g. Agile Manifesto, The Mythical Man Month, Code Complete)
August 16, 2022
In my experience, it is very rare that a book on software engineering is still significant after more than twenty years. Although Pete McBreen's book was published in 2001, almost the entire book seems very much relevant today. Yes, there are a few paragraphs that are a little dated (like the remarks on this very immature programming language called "Java"), but otherwise this book could have been written in 2022. There are a lot of statements that seem to address problems that I am facing every day as a software developer, and the proposed solutions make very much sense to me. Although McBreen's thoughts on Software Craftsmanship blend very well with agile methods and modern DevOps approaches, I guess there is still a long and winding road ahead when it comes to convincing software developers, and especially managers, of this approach which promises to produce high quality solutions very efficiently. At least I do not need to be convinced any more.
December 8, 2022
- The Hazards of the Good Enough Software Approach:
+ Is software more critical to your business and yet becoming bloated and buggier? I can remember the days when a word processor fitted on a single floppy; now it seems that we will soon be seeing applications that won't fit on a single CD. For many shrink-wrapped applications, each release seems to require that you buy more memory or get a faster machine. And most of the new features don't work very well.
+ Does your software look nicer but prove much harder to use? Sometimes it seems as if the developers spent so much time getting the application to look nice that they forgot that other people actually have to use the application.
+ Are projects taking longer and delivering less than promised? Vaporware is one of the wonderful terms that the software industry has added to our language. The first few releases may be out quickly, but each enhancement takes increasingly longer to appear as the software grows in complexity. Reducing the defect count to an acceptable level also takes longer as complexity grows.
+ Do the developers seem unresponsive to your needs when you report a defect? That is the reality of the engineering trade-off in the good enough software approach. If a defect affects only a small proportion of the possible users, it won't make economic sense to fix the problem. If you are lucky, a workaround will be found.
+ The good enough software approach is hazardous because it perpetuates the myth that defects are inevitable. The defects exist because of the crazy way that the software is developed. Good enough software is characterized by a coding frenzy to get an application feature complete, followed by an indeterminate period of testing and debugging. Small wonder that the cost of removing all of the defects is considered excessive, because most features have probably been implemented on top of existing errors. By separating the activities of coding and testing into distinct phases, the good enough software approach guarantees that the application will contain lots of defects.
+ Shipping software with known bugs is not a good idea. Even if all of the known serious or critical bugs are fixed, shipping with known bugs sends the wrong message. It says that you don't know how to fix the mistakes you have made in the software. Even worse, it suggests that you do not care about creating quality, reliable software. Ask any car dealership about how having a reputation for low reliability affects sales as soon as a high-reliability alternative becomes available.
- Is software development a mechanical task? I don't think so. Typing the code has never been the rate-limiting step, so physical analogies are not really appropriate.
Although we are familiar with simple mechanical analogies, these analogies cause us to make mistakes. The really common one is the old mathematical school puzzle: If two people can dig a hole in four days, how long will it take four people?
The standard textbook answer to this puzzle is two days, but the simple mathematical world rarely corresponds to reality. Before we can say whether adding more people is a good idea, we need to understand the problem first.
+ What is the rate-limiting step in the process? (Yes, we can dig faster, but we are limited by how fast we can pump the ground water out of the hole.)
+ What are the resource limits? (More people would be nice, but we have only one backhoe.)
+ What are the scheduling constraints? (The customer said the job had to start today and these workers were the only people we could find on such short notice.)
+ Is the problem decomposable? (The hole is so small that only one person can work at a time.)
+ Is there any point in finishing sooner? (The next tasks are already scheduled, and finishing earlier would just mean that the hole has longer to deteriorate before we pour the concrete.)
+ Are people interchangeable? (Training a good backhoe operator takes a while.)
- Software development works best when the developer has a deep understanding of the requirements, design, and source code. All of the hackers interviewed by Steven Levy did their own design and programming.
- Craftsmanship Encourages Developers to Write Great Software
- This book is a call to arms: We must insist that developers really know their craft before we trust them to create systems for us or with us. Whether you are a user, manager, or developer, it doesn't make sense to trust an inexperienced software developer. This is why we focus on software craftsmanship rather than on software engineering. The best processes in the world will not save a project from failure if the people involved do not have the necessary skills to execute the process; conversely, really good developers can make any process work.
- Craftsmanship is a better option, because we do not have to put in lots of defects and then spend money removing them again. We can all benefit from this reduction in wasted time, money, and effort.
- In the software development world, as of 2001, only the Open Source community comes close to the film industry in terms of openness about taking credit for work. If you see some Open Source code that you like, it's not hard to find the e-mail address of the author. Indeed, many software developers have built a very public reputation based on their contributions to Open Source systems and applications.
-The Challenge of the Mass Market
For some standard software applications, such as word processors, the cost of design and development of shrink-wrapped (off-the-rack) software can be spread out over literally millions of copies. This fact provides an interesting challenge for software developers, because it is not feasible to interview all users to determine their needs. As a consequence, shrink-wrapped software is sold on the basis of its features. Magazine reviews regularly compare applications on this basis and send the message that more features mean better software. These reviews also put pressure on organizations to be first with a feature or to respond quickly whenever a competitor includes a new feature in its product. Unfortunately, these same reviews rarely discuss bugs, so the response from organizations has been to sell good enough software.
- It is really a simple matter to create a robust core application that can be extended and enhanced. Using good design and careful modularization, developers have produced for themselves many tools that have lasted for many, many years. For some reason, however, they never got around to offering that type of application to their lusers.
- Software craftsmen can use this idea to challenge the good enough software approach. Develop a close working relationship with a small number of users, and then create the best possible application for these users. Make them ecstatic. Then the application will be ready for release to the mass market.
- The truly expensive part of software development comes in reducing the probability that hidden defects will cause problems.
- Not surprisingly, software craftsmen will look carefully at the reputation of the customer before agreeing to a project. They would be crazy not to. After all, their reputation is built on a series of successful projects. The key to a successful project is putting a good team of developers together with a good customer.
- To allow a developer to build a real reputation, software craftsmanship requires some changes to the relationship between developers and customers. In particular, developers must retain their moral rights (the right to claim authorship) in all of the applications they create so that other customers can find out what they have worked on. Retaining these moral rights is the key to a developer's reputation under the craftsmanship model. Rather than being known for their degrees, memberships, or certificates, the real credentials for developers consist of the applications on which they have worked.
- Hire Small Teams of Good Developers
Rather than hiring a horde of 30 or more average programmers, customers should hire 2 or 3 master craftsmen. Pay these craftsmen as much as you would have paid the horde of average programmers.
- What Is a Great Developer Really Worth? Probably a lot more than they are currently being paid as employees. They are worth at least five times, and perhaps ten times, what the average developer receives.
- Great developers are probably worthy of $150,000 to $250,000 per year. Average developers are probably worth less than you are currently paying them, and it is foolish to pay college graduates with no real-world experience $40,000 to $60,000 per year.
- Your task as a customer is to begin operating at the same level. Rather than sending questions and issues to be pondered by review committees, you need to empower your users to interact directly with your developers so that things can move quickly. You don't need multiple checks and balances because good developers know what is at staketheir reputations for successful delivery of high-quality, robust applications.
- Software craftsmen have a real interest in automated testing because of their investments in their reputations. In a way, this concept is a throwback to the practice of having installation verification procedures for applications. With these procedures, as soon as you installed a new version of an application, you could test that it actually worked.
- One of the key goals of incremental development is to get the application running early so that it can be tested. Once it is working correctly, it is conceptually quite simple to verify that all of the old features still work and that the new features perform correctly. Automated tests are necessary, because manual verification is both labor-intensive and error-prone. The practice of automating unit testing and functional, acceptance testing has been taken to new heights by eXtreme Programming.
- Cost/Quality Trade-off
You can request a set of features by a certain date, but because of the need to maintain a reputation for high-quality, robust applications, software craftsmen will value quality above the feature set. This preference is a natural consequence of the craftsmanship approach. In taking this approach, a customer makes a value choice, stating that having a high-quality, robust application is more valuable than feature set or delivery date. This trade-off requires a level of trust between the customer and the craftsman such that the customer gets the needed application without forcing the development team to compromise its reputation.
- In the Open Source community, becoming the maintainer of an application dramatically enhances your reputation. It signals that the original maintainer trusts the new maintainer to continue to maintain and evolve the application in a responsible manner for the good of the entire community. Such an honor is granted only to skilled developers who have made significant contributions to the application.
Contrast this idea with the software engineering view of maintenance. You get stuck in maintenance only if you are not good enough to work on new projects. After spending millions of dollars and many developer-years of effort on creating an application, the program is entrusted to the care of the lowest of the low. Crazy.
This attitude has even affected the way we speak about software through the use of the term legacy applications. Legacy applications are the core applications that enable a business to operate, but due to neglect are practically impossible to maintain and enhance. I cannot think of any other fields in which we are stupid enough to entrust the care and maintenance of essential, expensive assets to the people least qualified to look after them.
- The knowledge of how to do software development lies in the heads of the craftsmen. Developers are paid to think while they work. Software craftsmanship is an acknowledgment of the craft and skills of the developers. Managing craftsmen is different. People master a craft because they care enough about the craft to make the effort.
- Good Developers Are More Valuable Than Their Managers
This notion may come to a shock to some managers, but a really good developer is more valuable to an organization than the person who manages him. Managers need to get used to the concept of managing higher-paid employees. This outcome is a natural result of abandoning the software engineering approach of using hordes of average programmers and replacing those employees with a few good developers. Managing 30 programmers is a hard task, whereas managing 3 or 4 good developers is easy.
- Managers need to demonstrate that they value years of experience by providing training in the latest technologies to their old-timers. This may cost money and take some time, but most developers pick up new technologies surprisingly quickly. It's a better option than hiring a bunch of new developers who happen to know the technology. The new hires will have to learn the business and get to know their users.
- Even in traditional physical crafts like blacksmithing, 70-year-old master craftsmen are sought after for the quality of their work. Old-timers are valuable in any field; their depth and breadth of experience make a massive difference in the quality of their work. Craftsmen honor the past while enthusiastically learning in the present, so that in the future they can scale even greater heights.
- Craftsmen do not create something and then disclaim responsibility for it. Managers do not have to deal with the maintenance problem, because once a craftsman creates something, it is that person's creation to look after and enhance until the developer passes it on to a worthy successor. This process works because the creator's reputation is tied up in what they create. The Open Source community is a living example of this practice, and GNU Linux and Open Source tools exemplify this idea. Once a craftsman creates an application, she looks after it until it is no longer needed and can be retired.
- Journeymen are craftsmen who have finished their apprenticeships but have not yet mastered their craft. They work for master craftsmen from whom they could learn more and show the older apprentices how to do the more important and complex parts of the craft. When they have learned all they could from their original master, they know that the time has come to move on to a different masterhence the figurative and literal journey to mastery.
- Becoming a master software craftsman is not as simple as getting a certificate or passing an exam. Mastery is achieved by building a string of successful, robust, high-quality applications that lead to recognition by users, customers, and other developers. Developers know that they have achieved mastery of software craftsmanship when other developers seek them out to work with them, customers and managers want them to create applications, and users recommend their work. Building this kind of reputation takes time, but that is OK, because the applications that software craftsmen build are enduring as well.
- One widely held stereotype of companies that build PC products (or of California-based companies) is that they hire ''hackers'' and that their software is magic, unreadable spaghetti. Meeting with this group broke that stereotype for me. Their constant attention to architectural issues, their efforts to build an evolvable structure, their care to document the system well (both externally and internally) are all hallmarks of the highest professionalism. Those attitudes, coupled with the phenomenal general-purpose programming talents of the staff, plus the high level of domain-specific expertise, defined the kind of quality value system necessary to an effective and productive process. There were few gratuitous shortcuts and few novice errors. From what I saw, these people produce very high quality code.
- Design for testing discourages the creation of badly coupled code and encourages appropriate decomposition into cohesive modules. Indeed, object-oriented designs are especially sensitive to this effect. It is practically impossible to create good regression tests for badly coupled, object-oriented designs and really easy to create good regression tests for object-oriented designs that minimize unnecessary coupling.
- Design for Maintenance
There are two competing strategies for creating maintainable applications. The first strategy is to design configurable systems that have the necessary flexibility designed up front to cater for foreseen changes. The ultimate aim of this strategy is to create a system that is so configurable that most changes can be accomplished without having to change the application code.
The second strategy is to create simple systems so that it is a relatively quick and easy process to change the application to meet the changing requirements. The aim of this strategy is to defer investing in flexibility until there is definitive proof that the flexibility is necessary and cannot easily be accommodated just by changing the application.
- Great Software Is Global: Internationalization (I18N) and multilingualization (M17N)
- Great Software Needs to Be Given a Great User Interface
- Maintenance Is the Most Important Part of the Life of Any Application
- Software developers need to have a good memory, be very good at learning, and be great at forgetting. Forgetting is the most important ability because it is the key to perpetual learning. Learning is important because the field of software development is constantly evolving and changing. Every new application requires the developer to remember lots of new information and trivia. A key skill that developers need to master is the ability to forget the trivia while retaining the essential information. Starting out on the journey of perpetual learning is simple. An easy and effective starting point is to provide each development team with its own small library of good technical books. The Pragmatic Programmer by Hunt and Thomas is an ideal starting point, and its recommendations about building a library are spot on.
- Provide some time every week for your team members to goof off and learn something. Tell your developers to take one or two hours in the middle of every week to try out ideas that might improve their software development skills in a way that assists the current application.
- Putting the learning time at the end of Friday afternoon is less effective because it leaves no time to put into practice what was learned. The ideal learning time is Tuesday or Wednesday morning, when everyone is back into the flow of work and enough time remains in the week to try out new ideas.
+ Is software more critical to your business and yet becoming bloated and buggier? I can remember the days when a word processor fitted on a single floppy; now it seems that we will soon be seeing applications that won't fit on a single CD. For many shrink-wrapped applications, each release seems to require that you buy more memory or get a faster machine. And most of the new features don't work very well.
+ Does your software look nicer but prove much harder to use? Sometimes it seems as if the developers spent so much time getting the application to look nice that they forgot that other people actually have to use the application.
+ Are projects taking longer and delivering less than promised? Vaporware is one of the wonderful terms that the software industry has added to our language. The first few releases may be out quickly, but each enhancement takes increasingly longer to appear as the software grows in complexity. Reducing the defect count to an acceptable level also takes longer as complexity grows.
+ Do the developers seem unresponsive to your needs when you report a defect? That is the reality of the engineering trade-off in the good enough software approach. If a defect affects only a small proportion of the possible users, it won't make economic sense to fix the problem. If you are lucky, a workaround will be found.
+ The good enough software approach is hazardous because it perpetuates the myth that defects are inevitable. The defects exist because of the crazy way that the software is developed. Good enough software is characterized by a coding frenzy to get an application feature complete, followed by an indeterminate period of testing and debugging. Small wonder that the cost of removing all of the defects is considered excessive, because most features have probably been implemented on top of existing errors. By separating the activities of coding and testing into distinct phases, the good enough software approach guarantees that the application will contain lots of defects.
+ Shipping software with known bugs is not a good idea. Even if all of the known serious or critical bugs are fixed, shipping with known bugs sends the wrong message. It says that you don't know how to fix the mistakes you have made in the software. Even worse, it suggests that you do not care about creating quality, reliable software. Ask any car dealership about how having a reputation for low reliability affects sales as soon as a high-reliability alternative becomes available.
- Is software development a mechanical task? I don't think so. Typing the code has never been the rate-limiting step, so physical analogies are not really appropriate.
Although we are familiar with simple mechanical analogies, these analogies cause us to make mistakes. The really common one is the old mathematical school puzzle: If two people can dig a hole in four days, how long will it take four people?
The standard textbook answer to this puzzle is two days, but the simple mathematical world rarely corresponds to reality. Before we can say whether adding more people is a good idea, we need to understand the problem first.
+ What is the rate-limiting step in the process? (Yes, we can dig faster, but we are limited by how fast we can pump the ground water out of the hole.)
+ What are the resource limits? (More people would be nice, but we have only one backhoe.)
+ What are the scheduling constraints? (The customer said the job had to start today and these workers were the only people we could find on such short notice.)
+ Is the problem decomposable? (The hole is so small that only one person can work at a time.)
+ Is there any point in finishing sooner? (The next tasks are already scheduled, and finishing earlier would just mean that the hole has longer to deteriorate before we pour the concrete.)
+ Are people interchangeable? (Training a good backhoe operator takes a while.)
- Software development works best when the developer has a deep understanding of the requirements, design, and source code. All of the hackers interviewed by Steven Levy did their own design and programming.
- Craftsmanship Encourages Developers to Write Great Software
- This book is a call to arms: We must insist that developers really know their craft before we trust them to create systems for us or with us. Whether you are a user, manager, or developer, it doesn't make sense to trust an inexperienced software developer. This is why we focus on software craftsmanship rather than on software engineering. The best processes in the world will not save a project from failure if the people involved do not have the necessary skills to execute the process; conversely, really good developers can make any process work.
- Craftsmanship is a better option, because we do not have to put in lots of defects and then spend money removing them again. We can all benefit from this reduction in wasted time, money, and effort.
- In the software development world, as of 2001, only the Open Source community comes close to the film industry in terms of openness about taking credit for work. If you see some Open Source code that you like, it's not hard to find the e-mail address of the author. Indeed, many software developers have built a very public reputation based on their contributions to Open Source systems and applications.
-The Challenge of the Mass Market
For some standard software applications, such as word processors, the cost of design and development of shrink-wrapped (off-the-rack) software can be spread out over literally millions of copies. This fact provides an interesting challenge for software developers, because it is not feasible to interview all users to determine their needs. As a consequence, shrink-wrapped software is sold on the basis of its features. Magazine reviews regularly compare applications on this basis and send the message that more features mean better software. These reviews also put pressure on organizations to be first with a feature or to respond quickly whenever a competitor includes a new feature in its product. Unfortunately, these same reviews rarely discuss bugs, so the response from organizations has been to sell good enough software.
- It is really a simple matter to create a robust core application that can be extended and enhanced. Using good design and careful modularization, developers have produced for themselves many tools that have lasted for many, many years. For some reason, however, they never got around to offering that type of application to their lusers.
- Software craftsmen can use this idea to challenge the good enough software approach. Develop a close working relationship with a small number of users, and then create the best possible application for these users. Make them ecstatic. Then the application will be ready for release to the mass market.
- The truly expensive part of software development comes in reducing the probability that hidden defects will cause problems.
- Not surprisingly, software craftsmen will look carefully at the reputation of the customer before agreeing to a project. They would be crazy not to. After all, their reputation is built on a series of successful projects. The key to a successful project is putting a good team of developers together with a good customer.
- To allow a developer to build a real reputation, software craftsmanship requires some changes to the relationship between developers and customers. In particular, developers must retain their moral rights (the right to claim authorship) in all of the applications they create so that other customers can find out what they have worked on. Retaining these moral rights is the key to a developer's reputation under the craftsmanship model. Rather than being known for their degrees, memberships, or certificates, the real credentials for developers consist of the applications on which they have worked.
- Hire Small Teams of Good Developers
Rather than hiring a horde of 30 or more average programmers, customers should hire 2 or 3 master craftsmen. Pay these craftsmen as much as you would have paid the horde of average programmers.
- What Is a Great Developer Really Worth? Probably a lot more than they are currently being paid as employees. They are worth at least five times, and perhaps ten times, what the average developer receives.
- Great developers are probably worthy of $150,000 to $250,000 per year. Average developers are probably worth less than you are currently paying them, and it is foolish to pay college graduates with no real-world experience $40,000 to $60,000 per year.
- Your task as a customer is to begin operating at the same level. Rather than sending questions and issues to be pondered by review committees, you need to empower your users to interact directly with your developers so that things can move quickly. You don't need multiple checks and balances because good developers know what is at staketheir reputations for successful delivery of high-quality, robust applications.
- Software craftsmen have a real interest in automated testing because of their investments in their reputations. In a way, this concept is a throwback to the practice of having installation verification procedures for applications. With these procedures, as soon as you installed a new version of an application, you could test that it actually worked.
- One of the key goals of incremental development is to get the application running early so that it can be tested. Once it is working correctly, it is conceptually quite simple to verify that all of the old features still work and that the new features perform correctly. Automated tests are necessary, because manual verification is both labor-intensive and error-prone. The practice of automating unit testing and functional, acceptance testing has been taken to new heights by eXtreme Programming.
- Cost/Quality Trade-off
You can request a set of features by a certain date, but because of the need to maintain a reputation for high-quality, robust applications, software craftsmen will value quality above the feature set. This preference is a natural consequence of the craftsmanship approach. In taking this approach, a customer makes a value choice, stating that having a high-quality, robust application is more valuable than feature set or delivery date. This trade-off requires a level of trust between the customer and the craftsman such that the customer gets the needed application without forcing the development team to compromise its reputation.
- In the Open Source community, becoming the maintainer of an application dramatically enhances your reputation. It signals that the original maintainer trusts the new maintainer to continue to maintain and evolve the application in a responsible manner for the good of the entire community. Such an honor is granted only to skilled developers who have made significant contributions to the application.
Contrast this idea with the software engineering view of maintenance. You get stuck in maintenance only if you are not good enough to work on new projects. After spending millions of dollars and many developer-years of effort on creating an application, the program is entrusted to the care of the lowest of the low. Crazy.
This attitude has even affected the way we speak about software through the use of the term legacy applications. Legacy applications are the core applications that enable a business to operate, but due to neglect are practically impossible to maintain and enhance. I cannot think of any other fields in which we are stupid enough to entrust the care and maintenance of essential, expensive assets to the people least qualified to look after them.
- The knowledge of how to do software development lies in the heads of the craftsmen. Developers are paid to think while they work. Software craftsmanship is an acknowledgment of the craft and skills of the developers. Managing craftsmen is different. People master a craft because they care enough about the craft to make the effort.
- Good Developers Are More Valuable Than Their Managers
This notion may come to a shock to some managers, but a really good developer is more valuable to an organization than the person who manages him. Managers need to get used to the concept of managing higher-paid employees. This outcome is a natural result of abandoning the software engineering approach of using hordes of average programmers and replacing those employees with a few good developers. Managing 30 programmers is a hard task, whereas managing 3 or 4 good developers is easy.
- Managers need to demonstrate that they value years of experience by providing training in the latest technologies to their old-timers. This may cost money and take some time, but most developers pick up new technologies surprisingly quickly. It's a better option than hiring a bunch of new developers who happen to know the technology. The new hires will have to learn the business and get to know their users.
- Even in traditional physical crafts like blacksmithing, 70-year-old master craftsmen are sought after for the quality of their work. Old-timers are valuable in any field; their depth and breadth of experience make a massive difference in the quality of their work. Craftsmen honor the past while enthusiastically learning in the present, so that in the future they can scale even greater heights.
- Craftsmen do not create something and then disclaim responsibility for it. Managers do not have to deal with the maintenance problem, because once a craftsman creates something, it is that person's creation to look after and enhance until the developer passes it on to a worthy successor. This process works because the creator's reputation is tied up in what they create. The Open Source community is a living example of this practice, and GNU Linux and Open Source tools exemplify this idea. Once a craftsman creates an application, she looks after it until it is no longer needed and can be retired.
- Journeymen are craftsmen who have finished their apprenticeships but have not yet mastered their craft. They work for master craftsmen from whom they could learn more and show the older apprentices how to do the more important and complex parts of the craft. When they have learned all they could from their original master, they know that the time has come to move on to a different masterhence the figurative and literal journey to mastery.
- Becoming a master software craftsman is not as simple as getting a certificate or passing an exam. Mastery is achieved by building a string of successful, robust, high-quality applications that lead to recognition by users, customers, and other developers. Developers know that they have achieved mastery of software craftsmanship when other developers seek them out to work with them, customers and managers want them to create applications, and users recommend their work. Building this kind of reputation takes time, but that is OK, because the applications that software craftsmen build are enduring as well.
- One widely held stereotype of companies that build PC products (or of California-based companies) is that they hire ''hackers'' and that their software is magic, unreadable spaghetti. Meeting with this group broke that stereotype for me. Their constant attention to architectural issues, their efforts to build an evolvable structure, their care to document the system well (both externally and internally) are all hallmarks of the highest professionalism. Those attitudes, coupled with the phenomenal general-purpose programming talents of the staff, plus the high level of domain-specific expertise, defined the kind of quality value system necessary to an effective and productive process. There were few gratuitous shortcuts and few novice errors. From what I saw, these people produce very high quality code.
- Design for testing discourages the creation of badly coupled code and encourages appropriate decomposition into cohesive modules. Indeed, object-oriented designs are especially sensitive to this effect. It is practically impossible to create good regression tests for badly coupled, object-oriented designs and really easy to create good regression tests for object-oriented designs that minimize unnecessary coupling.
- Design for Maintenance
There are two competing strategies for creating maintainable applications. The first strategy is to design configurable systems that have the necessary flexibility designed up front to cater for foreseen changes. The ultimate aim of this strategy is to create a system that is so configurable that most changes can be accomplished without having to change the application code.
The second strategy is to create simple systems so that it is a relatively quick and easy process to change the application to meet the changing requirements. The aim of this strategy is to defer investing in flexibility until there is definitive proof that the flexibility is necessary and cannot easily be accommodated just by changing the application.
- Great Software Is Global: Internationalization (I18N) and multilingualization (M17N)
- Great Software Needs to Be Given a Great User Interface
- Maintenance Is the Most Important Part of the Life of Any Application
- Software developers need to have a good memory, be very good at learning, and be great at forgetting. Forgetting is the most important ability because it is the key to perpetual learning. Learning is important because the field of software development is constantly evolving and changing. Every new application requires the developer to remember lots of new information and trivia. A key skill that developers need to master is the ability to forget the trivia while retaining the essential information. Starting out on the journey of perpetual learning is simple. An easy and effective starting point is to provide each development team with its own small library of good technical books. The Pragmatic Programmer by Hunt and Thomas is an ideal starting point, and its recommendations about building a library are spot on.
- Provide some time every week for your team members to goof off and learn something. Tell your developers to take one or two hours in the middle of every week to try out ideas that might improve their software development skills in a way that assists the current application.
- Putting the learning time at the end of Friday afternoon is less effective because it leaves no time to put into practice what was learned. The ideal learning time is Tuesday or Wednesday morning, when everyone is back into the flow of work and enough time remains in the week to try out new ideas.
This entire review has been hidden because of spoilers.
December 9, 2021
I like the notion behind this book that software developers should focus less on going to classes and getting certifications and more on learning on the job. After 20 years as a software developer I've always felt that the computer science I learned in school just provided a foundation to go out and learn actual programming and software development. It's also why I think the concept of using applied projects to teach children works far better than abstract lessons.
That said, while a system of craftsmen, journeymen, and apprentices sounds more ideal than the current reality (or the reality of 20 years ago, when this book was written), it would take buy-in from the entire software development world to make it work. From the developers to the managers to the customers, everyone would have to change their mindset. Otherwise there's not really a good way to fit the true on-the-job training necessary to support the apprentice to journeyman to craftsman system.
There's an almost glancing mention of Agile at one point. Given the book was written in 2002, Agile has come a long way and solves some of the problems the author has with software engineering. Agile promotes smaller teams that have more interaction with each other and users or customers. A smaller team will naturally have to include a more senior developer to serve as the craftsman to the rest of the team. The roles in Agile and planning events help form a de facto hierarchy close to the desired craftsmanship model. Making developers assign points and agree to complete them in a sprint is very close to making a developer sign their name and stake their reputation.
I also didn't realize until about halfway through the book that I work on projects that the book says actually do require software engineering. Very long duration projects that require new hardware or other technology will require software engineering. Which means the projects the author thinks fit into the craftsmanship system are for shorter, more focused pieces of pure software. Again, this seems like what Agile is tailor made to work with.
The book gets a little scattershot. A whole section is devoted to developing software that is easy to maintain since the craftsman will be the maintainer. This feels like simple common sense, but I've never had the luxury of handing off software to a separate maintenance team. Even if I did, I would want to provide software that is easy for that team to maintain to ensure the company continues to put out a quality product. I am sure there are software engineers that treat their work and output like a factory worker, but I've never run into such a developer and most take pride in their code even without a signature.
I'm sure this book was groundbreaking if not blasphemous when it came out 20 years ago. Now it feels like just a motivational book to take pride in your work rather than a call to arms to change the industry.
That said, while a system of craftsmen, journeymen, and apprentices sounds more ideal than the current reality (or the reality of 20 years ago, when this book was written), it would take buy-in from the entire software development world to make it work. From the developers to the managers to the customers, everyone would have to change their mindset. Otherwise there's not really a good way to fit the true on-the-job training necessary to support the apprentice to journeyman to craftsman system.
There's an almost glancing mention of Agile at one point. Given the book was written in 2002, Agile has come a long way and solves some of the problems the author has with software engineering. Agile promotes smaller teams that have more interaction with each other and users or customers. A smaller team will naturally have to include a more senior developer to serve as the craftsman to the rest of the team. The roles in Agile and planning events help form a de facto hierarchy close to the desired craftsmanship model. Making developers assign points and agree to complete them in a sprint is very close to making a developer sign their name and stake their reputation.
I also didn't realize until about halfway through the book that I work on projects that the book says actually do require software engineering. Very long duration projects that require new hardware or other technology will require software engineering. Which means the projects the author thinks fit into the craftsmanship system are for shorter, more focused pieces of pure software. Again, this seems like what Agile is tailor made to work with.
The book gets a little scattershot. A whole section is devoted to developing software that is easy to maintain since the craftsman will be the maintainer. This feels like simple common sense, but I've never had the luxury of handing off software to a separate maintenance team. Even if I did, I would want to provide software that is easy for that team to maintain to ensure the company continues to put out a quality product. I am sure there are software engineers that treat their work and output like a factory worker, but I've never run into such a developer and most take pride in their code even without a signature.
I'm sure this book was groundbreaking if not blasphemous when it came out 20 years ago. Now it feels like just a motivational book to take pride in your work rather than a call to arms to change the industry.
February 19, 2019
Dated, but still worth a read. Old-fashioned concepts like "taking pride in your work"! No, seriously, software engineers should always put their name in their code so that they can be held to account for what they've done. I found this book inspired me to keep trying to master a skill that I have worked on for 30 years.
December 28, 2023
Software Craftsmanship finished, it seemed like another great book to have in the library (or anti-library). Describes the metaphor of seeing software development as a craft process in contrast to software engineering. We can see development in many ways and this is one of them, knowing how to choose the right metaphor for each project can help to know how to better focus them.
December 13, 2020
I really enjoyed reading this book and the ideal of practicing craft through Software Development. The ideas seemed a bit repetitive in the middle of the book, Part 3 and 4, but the final 3 chapters of the book are very valuable. This would need to re-read at times to keep refining one’s craft.
March 4, 2021
One of the best book of “Programmer’s non-programming book”
This classic already includes concept of Extreme Programming/Agile/DevOps/Full-cycle Engineer
This classic already includes concept of Extreme Programming/Agile/DevOps/Full-cycle Engineer
August 10, 2014
When you get down to it the points this book makes are very interesting. The author takes you on a journey to understand his dislike of the term software engineering. Followed by an exposition of the changes he'd like to see in the industry. The book is cogent and definitely sparked some of my own thinking about hiring and training developers.
Sadly the book has aged somewhat, as other reviewers have noted the discussion of motivation is facile in in that it only considers salary as a measure of reward. Although given when the book was published I think it's likely that McBreen could easily not have been exposed to startup culture. More importantly some of the changes advocated are more rotted in a society where the labour market is less fluid (like handover being a much complete activity). Finally the prose is not as engaging as I would have liked. If you compare to a Kent Beck book you're going to be sorely disappointed.
Overall there's a lot to like about this book and it is somewhat sad that in the intervening 13 years the industry landscape has not changed as much as wither McBreen or I would have liked. Having said that, read it and see if you can't get some of the ideas rolling in your own organisation.
Sadly the book has aged somewhat, as other reviewers have noted the discussion of motivation is facile in in that it only considers salary as a measure of reward. Although given when the book was published I think it's likely that McBreen could easily not have been exposed to startup culture. More importantly some of the changes advocated are more rotted in a society where the labour market is less fluid (like handover being a much complete activity). Finally the prose is not as engaging as I would have liked. If you compare to a Kent Beck book you're going to be sorely disappointed.
Overall there's a lot to like about this book and it is somewhat sad that in the intervening 13 years the industry landscape has not changed as much as wither McBreen or I would have liked. Having said that, read it and see if you can't get some of the ideas rolling in your own organisation.
August 30, 2016
A surprisingly easy read, Pete McBreen explains why the analogy of Software Engineering does not fit comfortably into most development companies even though it is often used this way.
Providing some history as to how the term Software Engineering originated he breaks the analogy down and provides an alternative; Software Craftsmanship. He argues this is a much better fit for most development companies not working on large scale industrial, hardware focused projects.
He believes that the old master/journeymen/apprenticeship model used by traditional craftsmen is the best template for structuring a development team, allowing for shared learning, productivity and effective delivery.
The book also has many practical examples of how to apply the practices of Software Craftsmanship to your company.
Definitely worth a read if you work in software development and have always wondered what the whole Software Craftsmanship movement was all about.
Providing some history as to how the term Software Engineering originated he breaks the analogy down and provides an alternative; Software Craftsmanship. He argues this is a much better fit for most development companies not working on large scale industrial, hardware focused projects.
He believes that the old master/journeymen/apprenticeship model used by traditional craftsmen is the best template for structuring a development team, allowing for shared learning, productivity and effective delivery.
The book also has many practical examples of how to apply the practices of Software Craftsmanship to your company.
Definitely worth a read if you work in software development and have always wondered what the whole Software Craftsmanship movement was all about.
December 20, 2010
I really liked the book's approach in explaining the value of the craftsmanship approach through the introduction of the current practices of software development. That set up the discussion to then compare the software engineering approach with the craftsmanship approach. I liked that the author mentioned when an engineering approach to developing software makes sense rather than just completely discounting that method of building software. All in all, its a great read for both managers & developers on how to build a good team of great developers & creating a nurturing environment where developers continue to hone their craft.
September 11, 2016
Pete explains how small software projects may benefit from moving away from the waterfall process. He advocates a "craftsmanship" model, where craftsmen—the maestros programmers—would take under their wings beginners and help them survive, strive and eventually master real projects.
In my view, this book reads very well. It turns out less provocative than I expected. The success of Agile methods has shown that, indeed, small teams may deliver great software. The challenge remains now to spot and detect these maestros, who I believe eventually turns to management activities as they climb the hierarchy ladder. Degrees and certifications are still alive and kicking ...
In my view, this book reads very well. It turns out less provocative than I expected. The success of Agile methods has shown that, indeed, small teams may deliver great software. The challenge remains now to spot and detect these maestros, who I believe eventually turns to management activities as they climb the hierarchy ladder. Degrees and certifications are still alive and kicking ...
April 10, 2017
IST SOFTWARE-ENTWICKLUNG HANDWERK ODER ENGINEERING?
Taugt industrielle Fertigung für Software, wie sie z.B. bei Hardware sinnvoll ist? McBreens „New Imperative" will vom Industrieproduktionsideal (zurück?) zum Manufakturmodell: Menschen mit Knowhow/Erfahrungswissen & Können wieder in das Zentrum der Programmierarbeit statt Menschen zu skalierbaren, entfähigten Anhängseln hochproduktiver Systeme & Prozesse zu machen, in denen das Wissen extern zukommt. Entwicklung vs. Produktion von Software.
Taugt industrielle Fertigung für Software, wie sie z.B. bei Hardware sinnvoll ist? McBreens „New Imperative" will vom Industrieproduktionsideal (zurück?) zum Manufakturmodell: Menschen mit Knowhow/Erfahrungswissen & Können wieder in das Zentrum der Programmierarbeit statt Menschen zu skalierbaren, entfähigten Anhängseln hochproduktiver Systeme & Prozesse zu machen, in denen das Wissen extern zukommt. Entwicklung vs. Produktion von Software.
November 23, 2021
I struggle to find the right way to express how to make software development right. I can’t say that I subscribe to every idea that is put forth by Software Engineering. The Software Engineering Institute does drive software development forward. However, having had the opportunity to listen to a few of the speakers that work for the SEI, I can’t say that I feel like they’re in touch with reality.
Click here to read the full review
Click here to read the full review
Read
June 3, 2016This is the book I was trying to find for a long time. It has some ideas I was thinking about but didn't know whom to ask. No it is much more clear.
Great book on work ethics for software craftsmen and a proper attitude for a variety of areas in our daily work.
I'm glad that it stopped me from reinventing the wheel and gave a clear answers for a lot of my long held questions.
I highly recommend this book for every software craftsmen who care about what they are doing.
Great book on work ethics for software craftsmen and a proper attitude for a variety of areas in our daily work.
I'm glad that it stopped me from reinventing the wheel and gave a clear answers for a lot of my long held questions.
I highly recommend this book for every software craftsmen who care about what they are doing.
January 2, 2017
A very good introduction to software craftsmanship. It is nice to see how relevant this still is today.
The book does seem to repeat itself a bit, which is good if this is the first you read about the topic, but otherwise be prepared to skim over repeated content.
If you like software Craftsmanship, a great follow up to this book would be The Software Craftsman by Sandro Mancuso, which is a great read and inspirational.
The book does seem to repeat itself a bit, which is good if this is the first you read about the topic, but otherwise be prepared to skim over repeated content.
If you like software Craftsmanship, a great follow up to this book would be The Software Craftsman by Sandro Mancuso, which is a great read and inspirational.
January 29, 2016
After taking many software engineering courses, I found McBreen's perspective refreshing. The author applies the traditional framework of mastery to programming, and explains why it would be a better fit for growing software engineers.
There are some minor typos in the book, but other than that it is a good and quick read.
There are some minor typos in the book, but other than that it is a good and quick read.
June 4, 2010
Not quite the level of "The Pragmatic Programmer", but still quite good. Anyone who views software design and programming as more of a craft than a science will really get a lot out of this book.
January 1, 2013
A good introduction to Software Craftsmanship, but extremely dogmatic and opinionated.
July 30, 2015
We as software developers should care deeply about the work product we produce. This leaves you with just that impression.
March 5, 2017
A very short review on my blog: http://filipin.eu/software-craftsmanship
Want to read
May 29, 2007Ken Gunn recommends.
April 5, 2017
This is a must-read for anyone interested in learning more about software craftsmanship with the caveat that the definition of software craftsmanship is probably still incomplete and being explored, even today. This book attempts to define it but I think it is only moderately successful because I simply can't see businesses adopting them wholesale. If nobody will adopt them, then maybe the model is incomplete or is not a good fit. I think that its true value is in helping to define what craftsmanship is not. That may sound strange, but if you read it you will understand where the lines between craftsmanship and software engineering are drawn, about the practices and characteristics that are common to good software craftsmen, and about why the traditional managerial attempts to apply mechanical thinking to the highly mental activity of software development are so inappropriate.
I found this book really enlightening and full of little insights and nuggets of wisdom. I did notice some of the things that other reviewers have cited, like repetition, a focus on salary as a measure of value for craftsmanship, a bit of an elitist view of development, and a clear frustration in the author's tone. I chose to either accept or look past all of that because I can empathize with the sentiments that the author has expressed.
This topic may not appeal to everyone. For developers who have the ability to be honest with themselves in terms of their own shortcomings, and for those with a software engineering background who are willing to hear what the author is saying, there is a deeper understanding about the roots of software development and possible paths to improve it. For developers who don't view software development as something that requires discipline and rigor (which is also a valid view since there's no single way to develop!) then this will seem overly constraining. Either way it's an interesting history lesson.
One clarification for a comment another reviewer made: the author does not say that 'software engineering is bad', he says that it isn't a good fit for the vast majority of software development projects out there.
The author's main gripe is with the scientific management theories that get in the way of good software development and the naive and usually disastrous approaches they lead to. I appreciate the way he's framed this because it's given me a way to communicate why that approach has been so ineffective.
I found this book really enlightening and full of little insights and nuggets of wisdom. I did notice some of the things that other reviewers have cited, like repetition, a focus on salary as a measure of value for craftsmanship, a bit of an elitist view of development, and a clear frustration in the author's tone. I chose to either accept or look past all of that because I can empathize with the sentiments that the author has expressed.
This topic may not appeal to everyone. For developers who have the ability to be honest with themselves in terms of their own shortcomings, and for those with a software engineering background who are willing to hear what the author is saying, there is a deeper understanding about the roots of software development and possible paths to improve it. For developers who don't view software development as something that requires discipline and rigor (which is also a valid view since there's no single way to develop!) then this will seem overly constraining. Either way it's an interesting history lesson.
One clarification for a comment another reviewer made: the author does not say that 'software engineering is bad', he says that it isn't a good fit for the vast majority of software development projects out there.
The author's main gripe is with the scientific management theories that get in the way of good software development and the naive and usually disastrous approaches they lead to. I appreciate the way he's framed this because it's given me a way to communicate why that approach has been so ineffective.
Displaying 1 - 24 of 24 reviews