I’d like to take a moment to publicly discuss my thoughts on Software Craftsmanship, a topic that has seen a bit of back and forth in the blog world after Dan North unleashed Programming is Not a Craft. You can find some of the responses at the bottom of this post by Martin Fowler.
The two main criticisms of the Software Craftsmanship Manifesto are that it encourages programmers to focus only on the code side, and the low barrier to entry to calling yourself a “Software Craftsman.” Allow me to address these points of criticism.
Criticism #1: Programmers will fall in love with the software at a technical level, at the expense of building software that makes users go WOW
Martin Fowler may be right that “those people who primarily self-identify as programmers feel a large part of their life is no longer important in the agile world.” They are important, obviously, but if they don’t feel important then that’s something that needs to be addressed. Part of me thinks that SC is a reaction to broken software organizations that discourage interaction between programmers and users, and so the programmers retreat into their coding cubbies and focus on the only thing they have control over – their technical practices.
Back when Alan Cooper was stuck in an MS-dominated paradigm, he wrote, “Programmers aren’t evil. They work hard to make their software easy to use. Unfortunately, their frame of reference is themselves, so they only make it easy to use for other software engineers, not for normal human beings.” Some people seem to fear that a focus on craftsmanship will lead to a world of well-tested, well-designed code that powers ugly software that is painful to use. I don’t think that’s the case. The common theme throughout Agile Roots 2010 was user experience, and how to get UX people working closely with programmers. The Agile testing crowd is trying to get the message out that testing is about understanding user expectations. When you get programmers, UXers, and testers collaborating, you have the holy trinity of software development – quality software that solves user’s problems, with no hidden surprises.
Criticism #2: Low barrier to entry to calling yourself a Software Craftsman
Anyone can sign his name to the manifesto and call himself a software craftsman. I can add my dog as a signatory if I want to. Apparently I’m supposed to believe that this cheapens the values expressed in the manifesto. The reality is that anyone can call himself anything he wants! I’m the President of the United States. I’m dating Angelina Jolie. I’m a member of the World Cup-winning US soccer team. You get the idea… Simply calling yourself something doesn’t make it so. Who decides what is a “true” software craftsman anyway? It’s up to you to decide whether people you interact with practice what they preach. The manifesto doesn’t say, “we are craftsmen” – it says “we aspire to be craftsmen.”
I can’t accurately assess someone’s technical abilities or theory of software development based on the presence of his or her name on the SC Manifesto. I’d be an idiot for trying. But I bet that I could share a beer with anyone on that list and have an interesting discussion about software. Even if they don’t test like I do. Especially if they don’t test like I do. It’s perfectly valid for people to hold different theories on how to build software. I think we’re all better off if we let those theories mingle with each other, evolve, and even blow up in our faces on occasion. At the very least, Software Craftsmanship provides one means of recognizing people who give a shit and are worth talking to.
What’s missing from this discussion?
SC discussions have focused primarily on the programming side, but it’s called the Software Craftsmanship Manifesto, not the Typing-code-into-my-One-True-Editor Manifesto. Programming is only one role in the software creation process. Wouldn’t it be great if testers and UXers could organize themselves into groups with hokey names, just like the Software Craftsmen? Then we could throw one big mixer and invent 99% of the world’s useful software. Perhaps they can rally under the banner of Software Craftsmanship. They should rally under the banner of Software Craftsmanship.
What are we really talking about?
I see the Software Craftsmanship Manifesto as an evolution of the Agile Manifesto. The key phrasing is not the “Not only…but” clauses, it’s “raising the bar of professional software development by practicing it and helping others learn the craft.” Let’s examine it in detail:
raising the bar – Nobody has a clue how to objectively assess the best software people. That’s why licensing boards are so potentially dangerous to the industry, and why certifications are so useless. If we want to achieve progress, it is the practitioners that must take responsibility for elevating the industry.
practicing software development – Most professions devote as much time to practicing as they do to performing. Yet for some reason we approach every day like we’re completely prepared for what’s to come, despite working on problems riddled with uncertainty. SC says that we must acknowledge, respect, and prepare for the difficulty inherent in our work. SC says that the state of the art changes so rapidly that you must continually hone your skills if you are to build useful software over a span of years or decades. SC says that we must not let ourselves become complacent in our abilities, or make excuses for cutting corners. If your programming environment doesn’t provide automated refactorings, then you had better practice common reactorings so that they become second nature to you, and so that you can execute them swiftly and safely on production code. Above all, SC says never to let “too much work” get in the way of “a job well done.”
helping others learn – this is the crux of the manifesto, because software development is fundamentally an iterative learning process. When we share our experience and knowledge with others, we allow them to benefit from our past successes and failures. When we teach, we also learn, and the mixing of ideas allows us to expand the adjacent possible.
I was in Chicago for Agile 2009, the huuuge Agile conference filled with way more scrummasters than programmers. It’s where I met Corey Haines, or more specifically I was at David Chelimsky’s house pairing on RSpec when Corey Haines walked through the door and greeted me with a big hug. If you know Corey, you know that’s not a strange way for him to greet a stranger. Corey told me about the Software Craftsmanship conference taking place across the street from AgileConf and said that I should come. Some folks whose work I admired would be speaking, like Uncle Bob and Michael Feathers, and I would be exposed to other smart people in the software world who I hadn’t heard of before. I almost didn’t go, because I didn’t have enough money in my checking account to both pay for the conference and get my bills paid that month, but after a few hours of deliberation I held my breath and fired off an email to Corey asking if he could spot me the registration fee. He was in the middle of his pair programming tour where he basically worked for peanuts to put gas in his car to get from place to place, so he wasn’t exactly in the best position to lend me cash. I’m incredibly grateful that he did, because it was one of the best conferences I’ve been to in my life. There were talks about design, refactoring, compilers, required reading for programmers…Ken Auer even spoke about achieving a balanced life by picking four key areas of focus. Programmers…talking about life balance??? I thought we’re supposed to be locked away in our code caves for 72 hours straight surviving on cold pizza and jolt cola! Clearly this whole software craftsmanship thing is a different way of looking at software development. But how exactly?
The Software Craftsmanship Manifesto is valuable because it provides a goal – raising the bar – and a blueprint for getting there – practice, practice, practice, and help others learn. SC may run the risk of creating an echo chamber and excluding people who are capable of contributing valuable insight to the conversation, but I’m not afraid of that happening because at its core, SC is about sharing and being open to ideas for how to build software. Without SC and similar movements, we run a far greater risk of believing that we’re alone in the battle against crappy software, instead of recognizing that we’re part of a vibrant community of thinkers and practitioners who want to change the world.
You know that folder you’ve got filled with coding projects that never made it off the ground?
- code snippets that could become libraries, with a few tests
- libraries that could become gems, with some new documentation
- gems that could become side projects, with a bit of refactoring
- side projects that could become products, with the right game plan
You start each project with the best intentions, even big plans for some of them… but then life gets in the way, and you focus your attention on more important things. Then when you get some free time you dream up another project, and the cycle repeats itself.
You know that you can ship – you get all kinds of other projects out the door at work. Why do your open source ideas collect dust and regret?
The rules you apply to get stuff done at work don’t apply to your hobby projects. If you take the objective-driven approach you use in your work and try to use it on your hobby projects, you will continue to fall short of your goals – and keep piling on the guilt.
You can break the cycle, by launching one of your open source project ideas. You can push the spiral upward, by getting one project out the door and moving on to the next one.
You just need to learn a few skills and techniques that will help you dig in to your project graveyard and bring your projects to life.
Get Hack Your Open Source Project for FREE and you will: