There?s this conversation rolling around the developers? world; itstarted with chapter inCoders at Work by the one & onlyJWZ, which I haven?t read, but whichJoel Spolskyenthused 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 JWZsays, since he?s shipped more code that more people have used than any dozenor 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 towrite code to a higher level of abstraction than, say, C and Unix system callsprovide, but when you?re eight levels up the stack in something like Spring orWebsphere, 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 aboutall those levels.

TDD I

Joel is wrong to piss on unit testing, and buys into the commonfantasy 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 itdoes, 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 thatI?m using the onlineReal World Haskellbecause I would have launched a physical book across the room during theextended snotty lecture about how those poor dynamic-language programmers haveto use unit testing because they lack the miraculous benefits of strong statictyping. Static typing is not a substitute for unit testing. Sheesh.

Uncle Bob piles on: ?Programmers who say theydon?t have time to write tests are living in the stone age. They might as wellbe saying that man wasn?t meant to fly.?

Problems and Solutions

But then he says (slightly paraphrased): ?I think that any programmerthat?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 todoom 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 wellenough to avoid deadlocks and races and horrible non-repeatable bugs. Andthat COM was one of the most colossal piles of crap my profession ever foistedon itself.

I?d like to agree with Bob?s basic argument, but I don?t think we?re inagreement on problems and solutions.

Consider the Passenger

Let?s go back to the issue of complexity and layering. My own mostsuccessful software productions have been down-to-the-metal stuff, usually inC, full of memory-mapping and byte-level I/O. But these days, you can getfantastic results with certain highly-layered approaches.Consider my recent write-up onRavelry, which is built inRails, itself a pretty high stack of abstractions.They?re running it viaPhusion?s Passenger.

Similarly, check out some recent DHH tweets, which I?ll reproduce forconvenience:
Basecamp is now handling more than 50 million Rails requests perweek. We're peaking out at around 200 req/sec. Damn! (*)

Basecamp's average response time is 90ms and 87% of all requests finish inless than 200ms. Great stats thanks to jumping off virtualization.(*)

Basecamp runs on 4 dedicated Dell R710's (2xL5520@2.27Ghz CPUs with 12GBRAM) serving Rails through Apache/Passenger. Zippy bastards!(*)

Another Passenger success story. And what is Passenger actually? It?s anApache module. For those who don?t know, an Apache module is about asclose to the raw metal as you can get in Web infrastructure; uncompromising Ccode where you get to munge each request as the server works itshighly-optimized way through the business of parsing and dispatching it anddelivering the results.

This seems like existence proof of the assertion that layering is your friend (as in all that Rails machinery making Ravelry and Basecampmaintainable), but so is being close to the metal (Passenger?s C codegreasing the path between the Internet and the app).

TDD II

If you read the comments around this debate, it?s increasingly obviousthat we as a profession don?t have consensus around the value of TDD.Many of our loudmouths (like me for example) have become evangelists probablyto the point of being obnoxious. But there remains a strong developer factionout there, mostly just muttering in their beards, who think TDD is another flavor of architecture astronautics that?s gonna slow them down andget in their way.

I think we need to bash this out in public. We need to organize a goodhead-to-head practitioners? debate at a conference or on some good onlineproperty, and see if we can at the very least come to a good understanding ofour disagreements.




More...