So, Joel has posted something that is causing a bit of discussion (if you don’t need substance and want to kill half an hour, click ). Though there are many points of interest in his post, I’m guessing that one of the passages that caused the most consternation was this part:
Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”
In a previous kerfuffle, Joel seemed to be denigrating unit testing in general and TDD in particular, and this naturally got the Craftsmanship Fascists’ panties in a bunch. A large part of the difficulty is that people are talking past each other. This is normal, by the way. Communication is possible, but it is also hard. Joel seems to equate TDD advocates with architecture astronauts, which is obviously wrong. The Craftsmanship Fascists (CF from here on out) seem to think that the ‘duct tape programmer’ is just someone who throws some crap code together and slams it into production and hopes for the best, which is also obviously wrong. Luckily, I’m here to help.
You aren’t a duct tape programmer
Joel explicitly makes the point that the people whom he would call duct tape programmers are few and far between:
One thing you have to be careful about, though, is that duct tape programmers are the software world equivalent of pretty boys... those breathtakingly good-looking young men who can roll out of bed, without shaving, without combing their hair, and without brushing their teeth, and get on the subway in yesterday’s dirty clothes and look beautiful, because that’s who they are. You, my friend, cannot go out in public without combing your hair. It will frighten the children. Because you’re just not that pretty. Duct tape programmers have to have a lot of talent to pull off this shtick.
The average schmuck writing code isn’t one of these. Part of the issue here, I think, is that the CF group denigrates duct tape. Duct tape saves lives. Don’t believe me? Check here and look at the section on Apollo 13. Case closed. Regardless, it is clear that what Joel is talking about is not about randomly slinging shit together and hoping for the best. It is instead that the end goal is what matters, and it doesn’t matter if there are people who think the processes that lead to a successful end goal think it is pretty or shiny enough. This is why he says that shipping software is what matters. He is completely right about this.
Cowboy Programming
During the dot.com phase of my career, our company purchased a site that (for whatever reason lost in time) needed to be converted to something that was on our platform. For various reasons (lost in time), the item on the task list (or whatever it was) sat there for quite a while, until a cowboy programmer decided to rectify the situation.
I’m using the phrase ‘cowboy programmer’ here in the (normally understood as pejorative from an agile perspective) sense of someone who doesn’t follow TDD/XP/Agile/Whatever and just codes what he feels is right to get the job done. In many, if not most, situations, cowboy programming is looked down upon, and with good reason.
The thing is, this guy was good (Hey Keith!). He, more or less, locked himself into a conference room over a weekend and ported the site to our platform. He certainly didn’t do TDD. He definitely didn’t have detailed requirements. The requirement was '”port site to our platform.” And because he was so talented, he did met that requirement.
When you have the talent, being a duct tape cowboy programmer lets you be able to accomplish a lot of things that seem to bypass all of the CF standards that are supposedly so important. But, the kicker is that you have to have the talent.
Laziness
One of my high school Physics teachers used to say something like “Intelligent people are inherently lazy. They don’t want to spend time doing more work than necessary to get a job done.” I’m pretty sure this was not a vocational message approved by the Administration.
Anyway, I can relate. When I was doing the whole dot.com thing, I was motivated. Really motivated. Like many of my co-workers, I had visions of retirement at age 30 from all of those stock options. Regardless of the visions, I was hot shit. I could work 80 hours a week, I could be assigned tasks that I’d never ever worked on before and fulfill those tasks as if I was an expert. We rocked as a team and as individuals. And I was a perfectionist. I hated when things didn’t work right. Our team took over the websites for the NHL at one point, and I remember being angry when the CEO talked about how happy he was about the flawless launch. It wasn’t flawless. The individual team sites didn’t work for at least 12 hours (can you imagine!) because of some bugs we didn’t anticipate. Flawless! Please.
Fast forward a bit. I’m still a perfectionist but understand a little bit more about what ‘flawless’ means. It means providing the expected business value within a reasonable timeframe. And what counts as ‘reasonable’ and ‘expected’ is defined by the business, regardless of what my perfectionist nature prefers.
More importantly, I’m lazy (or perhaps it is just that I’m tired). I don’t want to work 80 hours a week, I don’t want to work on oddball tasks, and I don’t want to have to fix things. So, I write tests because I know well enough by now that if I try to code something without them, I am much more likely to make some mistakes that won’t be found until I run the application, launch the web site, etc. I want the flexibility to be able to change some code (because the requirements changed two days before production migration) and click a frickin’ button and see green, or (perhaps) better, see red and know I have some things to fix. Actually, I want to be able to click a button and see gray, but that’s another story.
So, is Joel correct?
The answer is, of course, yes…but. The ‘yes’ is that software is there to fulfill some requirements. The nature of those requirements is determined by the nature of the business. Unless the business requires the shiniest of software as imagined by the CF group, quality is tangential. Ship what is required.
Then there is the ‘but’. Things like unit testing are preferable to the typical developer like me because they allow me to fulfill the requirements of the business in the safest, easiest manner. I know, from personal experience, that the time I don’t spend using SOLID principles, unit testing, etc. will probably be spent, on an order of magnitude higher, in a debugger trying to figure out what went wrong. I’m experienced enough to know when a certain code path is most likely to cause me pain down the road, and because I know this, I know it is best to create tests around those areas. Do I need to have 100% code coverage? Of course not. Only the CF group thinks that. But don’t think you can ignore setting up tests where it is required, unless you are a duct tape cowboy.