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 issuescome 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:
- 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.
- 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:
- 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.
- 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.
Interesting post. I liked the story about instrument repairs and the warning is contains.
ReplyDeleteI am one of those "software craftmanship advocates", and I'm certainly agreeing with you that one should take a holistic view and not mindlessly chase some abstract concept of perfection.
What I disagree with is that this is what software craftsmanship is about. On the contrary. At it's core it's about professionalism, which entails doing what is of most interest to your client. That is simply not possible with a singular focus that ignores the actual circumstances. Of course there will be people that say they follow software craftsmanship principles while they don't, just like you got software architects that have not touched code for years.
A second point that I do not agree with is one that is only in-explicitly made: that one needs to choose between quality and speed/cost. This is true for most things, such as instrument repair. A skilled person can create a well designed and tested non-trivial system faster than doing it without tests or refactoring. Skill and education are the bottleneck.
Thanks for the feedback. You've made me rethink something in my article. My issue isn't with the idea of software craftsmanship itself. My issue is that there are a lot of programmers who don't understand that some tools/approaches are only appropriate for some situations. Unit testing is great, but 100% code coverage is overkill. (I've written about that elsewhere. Let me know if you want me to dig that up.) Abstraction is great, until everything is so abstracted you don't know what is going on in the app. Software craftsmanship, at least from my perspective, should be exploring the boundaries of what is appropriate for each situation, and instead is presented in such a way that legitimizes the one-size-fits-all approach to software development, regardless of whether you're making a mobile app or a behemoth desktop app.
DeleteAlong the same lines and to your second point, there *absolutely* is a trade-off between time-to-market, quality, and cost, though it's a bit more complicated with software because focusing on lowering costs in an unproductive way will raise costs in the long run. But my point really was more about appropriateness for a situation. I read a story once about a developer who spent a day adding a feature to a software product, only to have his manager say "almost done, but it needs an API", then spending three days breaking code in order to make that API which wasn't needed in the first place. If done right, software craftsmanship should be stopping this type of behavior, but instead encourages it.
Are there people in software craftsmanship who use the ideas to make themselves better? Absolutely, and they should be applauded. It's those that use it to justify putting $600 worth of repairs into a brand new $600 flute that worry me.