Does software craftsmanship make project success harder to attain?

There's a relatively new movement among software developers called software craftsmanship that focuses on improving the practices of software developers. On the surface, it seems like a good movement. After all, given the visible failures of software (the Affordable Care Act website failure and the Toyota accelerator issues come to mind), it is easy to blame the developers. But it would be hard for me to depend on a software craftsmanship advocate to deliver a software project successfully. To see why, I'd like to tell you about my first career.

Life as a flute repairman

When I was getting my undergraduate degree in music, I kept hearing how there weren't enough band instrument repairmen around, and those that were there weren't very good. Since there weren't many jobs available to musicians, I chose to be an instrument repairman, focusing on being the best that I could be. I quickly discovered that most musical instruments were shoddily made, and that if I wanted to bring out the best in them I needed to do a lot of work to get them to play well. As I gained experience, I found ways to be more efficient (and therefore more profitable to the music store), but I used those efficiencies to look for ways to make better repairs, not ways to do more of them.

One day, I realized two things:

1. My focus on making great repairs succeeded. I think that my repair abilities would have compared favorably to nationally-respected individuals. But I wasn't profitable. I'd put $600 of repairs into an instrument that cost the store about half that. That isn't a sustainable business model.
2. Many of the repairs I did made the instruments incredibly responsive and easy to play, but those same repairs made the instruments less tolerant to misalignments. That's fantastic for a professional player who can tell the difference, but a questionable thing to do for beginning students who can't tell the difference between a problematic instrument and poor playing.

Try as I might, though, I could not bring myself to lower my standards so I could achieve greater profitability or make instruments more tolerant of misalignments. So I left the industry and became a Web developer.

What does that have to do with software development?

If I were to be completely honest, if I were to pick up a flute now, nearly 10 years after I left the music industry, I'd still be unwilling to find the appropriate cost/quality/maintainability balance appropriate for each situation. I'd still want to do the best job possible, making the same repairs on a $10,000 flute and a $600 one. But as a software developer, I am not tied to a self-defined set of criteria for high quality. Between quality, cost-of-creation, long-term maintainability, and time-to-market, there is no single correct balance for software projects. The balance I'd choose for a short-term marketing project is very different from the balance I'd choose for a mission-critical project for a nuclear power plant.

Where software craftsmanship comes in

When I look at the software craftsmanship movement from a high level, I see many good ideas. Like I was 15 years ago, they are focused on turning around the perceptions of a failing industry. But I can say from personal experience that such a singular focus can make it impossible to see the bigger picture. Just like I was unable to change my approach for the situation because it felt like I was lowering my standards, most software craftsmanship practitioners focus on what's "right," regardless of the actual circumstance. As a representative example, automated unit testing is definitely a good thing, but when taken to the level of full Test-Driven Development espoused by software craftsmen, you end up with a tangled, unmanageable mess. And I think it's no coincidence that a large number of people leading the "No Estimates" movement are also sympathetic to the software craftsmanship movement.

Software craftsmen and delivering projects successfully

It should come as no surprise that software developers who are most passionate about doing the best job they possibly can are often the best developers on a team. But if your best developer is a software craftsman, you must resist the temptation to put that person in charge of the development team as a whole for two reasons:

1. To deliver the project successfully, your team leader must understand when high quality is vital to success and when additional quality adds unnecessary costs and/or delays.
2. To get the most out of your software product, you need a software leader who understands the business need well enough to be able to anticipate problems and suggest solutions. Someone hyper-focused on their own part of the process typically isn't able to do this well.

Yes, this presents a management and leadership challenge by putting a seemingly inferior developer in charge of the development effort. But if you think about it, that would be the best approach for everyone. It gives the software craftsman the opportunity to focus on what he/she is clearly most passionate about but allows the team to direct that passion for the betterment of the project.