There’s this conversation rolling around the developers’ world; it started with chapter in Coders at Work by the one & only JWZ, which I haven’t read, but which Joel Spolsky enthused over, praising the practice of “duct-tape programming”. Uncle Bob Martin weighed in. I have opinions and examples too.
First, Joel is right that you want to pay attention to what JWZ says, since he’s shipped more code that more people have used than any dozen or two average programmers. Also he’s funny. So I’ll buy that book.
Joel is right that complexity is your enemy. We’d all like to write code to a higher level of abstraction than, say, C and Unix system calls provide, but when you’re eight levels up the stack in something like Spring or Websphere, chances are one or two of the levels are going to generally suck, because that’s how life generally is. So it’s really sensible to worry about all those levels.
TDD I · Joel is wrong to piss on unit testing, and buys into the common fantasy that it slows you down. It doesn’t slow you down, it speeds you up. It’s been a while since I’ve run a dev team, but it could happen again. If it does, the developers will use TDD or they’ll be looking for another job.
In related news, I’m trying to learn Haskell, and it’s a good thing that I’m using the online Real World Haskell because I would have launched a physical book across the room during the extended snotty lecture about how those poor dynamic-language programmers have to use unit testing because they lack the miraculous benefits of strong static typing. Static typing is not a substitute for unit testing. Sheesh.
Uncle Bob piles on: “Programmers who say they don’t have time to write tests are living in the stone age. They might as well be saying that man wasn’t meant to fly.”
Problems and Solutions · But then he says (slightly paraphrased): “I think that any programmer that’s not smart enough to use templates, design patterns, multi-threading, COM, etc is probably not smart enough to be a programmer period.”
What?! My experience suggests that there are few surer ways to doom a big software project than via the Design Patterns religion. Also, that multi-threading is part of the problem, not part of the solution; that essentially no application programmer understands threads well enough to avoid deadlocks and races and horrible non-repeatable bugs. And that COM was one of the most colossal piles of crap my profession ever foisted on itself.
I’d like to agree with Bob’s basic argument, but I don’t think we’re in agreement on problems and solutions.
Consider the Passenger · Let’s go back to the issue of complexity and layering. My own most successful software productions have been down-to-the-metal stuff, usually in C, full of memory-mapping and byte-level I/O. But these days, you can get fantastic results with certain highly-layered approaches. Consider my recent write-up on Ravelry, which is built in Rails, itself a pretty high stack of abstractions. They’re running it via Phusion’s Passenger.
Similarly, check out some recent DHH tweets, which I’ll reproduce for convenience:
Basecamp is now handling more than 50 million Rails requests per week. We're peaking out at around 200 req/sec. Damn! (*)
Basecamp's average response time is 90ms and 87% of all requests finish in less than 200ms. Great stats thanks to jumping off virtualization. (*)
Basecamp runs on 4 dedicated Dell R710's (2xL5520@2.27Ghz CPUs with 12GB RAM) serving Rails through Apache/Passenger. Zippy bastards! (*)
Another Passenger success story. And what is Passenger actually? It’s an Apache module. For those who don’t know, an Apache module is about as close to the raw metal as you can get in Web infrastructure; uncompromising C code where you get to munge each request as the server works its highly-optimized way through the business of parsing and dispatching it and delivering the results.
This seems like existence proof of the assertion that layering is your friend (as in all that Rails machinery making Ravelry and Basecamp maintainable), but so is being close to the metal (Passenger’s C code greasing the path between the Internet and the app).
TDD II · If you read the comments around this debate, it’s increasingly obvious that we as a profession don’t have consensus around the value of TDD. Many of our loudmouths (like me for example) have become evangelists probably to the point of being obnoxious. But there remains a strong developer faction out there, mostly just muttering in their beards, who think TDD is another flavor of architecture astronautics that’s gonna slow them down and get in their way.
I think we need to bash this out in public. We need to organize a good head-to-head practitioners’ debate at a conference or on some good online property, and see if we can at the very least come to a good understanding of our disagreements.