I don’t want to talk about separating out good developers from bad ones. This happens naturally enough if you have a good interview and probation process. Be honest, see things as they are, and you will identify genuinely good developers. Instead, I want to talk about Software Craftsmanship as a movement. I’ve been lurking within the Software Craftsmanship community for a while and I am disgusted by much of what I am seeing from the talkers. Every group like this has at least two factions:
- Folks who want to proselytize. This group derives their self worth from speaking on the topic and explaining why anyone not following their practices is an armpit sniffing moron.
- Folks who take the good ideas and use them. This camp is too busy doing a better job today than they did yesterday to spend time converting others.
Software Craftsmanship as a whole has some fairly good ideas:
- Test Driven Development: Write tests before you write the actual code. This practice has some great benefits. Code winds up being very usable because the code is written with a focus on the consumer of the code instead of the producer. The code tends to be fluent and have simpler parameter lists.
- Always be delivering something: Part of scrum, a development team performs best when their time horizon is always 1-3 weeks out. This also allows for a tighter feedback loop since the consumer always has something they can use. As the requirements and reality converge, less time is wasted on things that are wrong.
- Continuous Integration: You should always have a buildable system. A broken build is a show stopper for the person who broke things. Even better, have a staged build system where the developer checkin is built on a ‘clean’ machine, has all tests run. If the build fails or any tests fail, the checkin can’t go through. This keeps the build clean all the time. (We did this at Microsoft for WCF. It was great being able to always get a clean build at any time of the day or night.)
- Monitor code coverage: Look what blocks of code are NOT covered. By analyzing what parts aren’t tested, you can learn where you are missing tests. After all, we are going to miss things when practicing TDD. Code coverage lets us know when we skipped step.
- YAGNI: You aren’t going to need it. This stops us from worrying about every imaginable use case for the feature. Satisfy the customers you know about, design for ease of change via solid tests. When those use cases appear (later), you can re-run the tests to make sure adding the use case left the system in a stable state.
- When checking in a bug fix, check in a new test that verifies the bug was fixed. This step prevents regressions, and regressing is always more expensive than writing a test.
- Inversion of Control/Mocks: Programming to interfaces allows for looser coupling between systems. Looser coupling allows developers to work on dependent features simultaneously. Once the features are ready, the two can use a day or two of pair programming to wire the features together.
There are more items. My point is-these are all good ideas. These ideas are NOT a methodology. I used all of these features at Microsoft from 2000-6. I’m sure that Microsoft was doing this long before I showed up. When you build software, you need Build Verification Tests (aka TDD). You should have mechanisms in place that guarantee that the build is always valid. You should be able to design features in parallel-mechanisms used to design features in parallel also makes those features easier to test and diagnose!
This is where I have my issues with the Software Craftsmanship community. You aren’t superior to anyone. Your ideas aren’t new-they are OLD. Mechanical engineers and electrical engineers have known these tricks for a long time. So have carpenters, electricians, and any other craftsman. I have no issues with educating developers on how to raise the level of quality. Stop writing manifestos and just teach your fellow programmers how to do a good job. Explain why you do what you do so that we may learn what practices work. Drop the attitude of superiority though. I can’t stand to listen to you. Your rhetoric blocks the real message-that these practices actually allow people to get more done with fewer errors. That they allow for creativity of the group to flourish and for cooperation to work better.
I think there is a lot of potential in Software Craftsmanship. I think a better focus on the practices and away from the ‘movement’ aspects will win more often. The vocal members of the group like feeling superior instead of being helpful. I can’t get behind that kind of thing.
Karmic Code Monkey 