Reading The Duct Tape Programmer really hit a nerve with me. If you code for a living (or part of your living), go read it. I sometimes get annoyed by Joel Spolsky's writing, but this time he hit the nail right on the head.
I am by no means putting myself in the same league as Jamie Zawinski, but I definitely subscribe to the idea that keeping my code as simple as possible is going to pay big, big dividends in the long run.
Needless complexity really does kill you.
In my work it has manifested itself in a few ways. But one that seems to pop up over and over in recent times (and has bitten a few of my coworkers as well) is socket programming. For whatever reason, we're able to find the the freely available client libraries for interacting with some services will inevitably fail a small but non-zero percentage of the time. And when you're making millions and millions of calls or connections per day, even a 0.01% failure rate is enought to make for a really bad day.
That's especially true when the failure mode involves leaking file descriptors or needlessly long timeouts (or timeouts that fail to work properly) that result in a full or partial cascading failure. It's the ultimate in frustration.
I'm not going to name names here. Maybe at an upcoming conference I'll talk about what we've seen and how network oddities add a whole new set of failures to the mix.
Anyway, the solution ends up being one of two options: (1) forking the module and re-writing the code to use the low-level system calls instead of the multitude of abstraction layers that were supposed to make the task easier (die abstraction layer! die!), or (2) scraping the module entirely and writing your own. The first option sucks but at least you're not having to learn all the quirks of those abstraction layers. The second option sucks even more but at least you know exactly what you've got when it's all said and done.
For me it's more satisfying and productive get to know the low-level stuff well enough that you can just drop it in when you need it. It's less frustrating than trying to reproduce all the conditions and variable that cause some abstraction layer to fail.
Pass the duct tape. I've got work to do!
Posted by jzawodn at September 23, 2009 08:40 PM
I liked the "Duct Tape Programmers" article. I *think* I agree with it.
The problem is I've known too many people who thought that they were duct tape programmers when they weren't.
You know, the sort of person who will happily patch one line in the live code, right there in live, because you think you've found a problem. Why wait? "It will only take a minute". Testing? No, the users will let us know if it goes wrong. Besides, I'm almost certain that it's right.
Give a couple of guys like this the root password for a month or two, and I guarantee that after a month your code will be unmaintainable.
So, yes to avoiding complexity. "As simple as possible but not simpler." No to just banging out code as fast as possible and hoping things will make sense later. Because they won't.
Just to prove the success of the Zawinski model -
How much of his code is still used anywhere?
Oh yeah - it's not.
While Netscape was stuck in the morass of fixing Zawinski's completely broken spaghetti code, Microsoft drove a truck through the company's front doors and stole all the customers with a better designed, more tested product. Turns out that duct tape doesn't last very long.
I agree with simplicity - everyone does. But I disagree completely with the idea of not testing. Testing is a fundamental part of any science. There are too many, like Zawinski that make completely broken software and get away with it. Your code simply won't stand the test of time without solid, vigorous, well-engineered automated tests.
Jamie Zawinski bailed on the software industry ten years ago- or a century in internet time, and it is being argued by many programmers today that he was never that good of a programmer even while he was at Netscape. Modern software engineering would no doubt be completely unrecognizable to him, as would web engineering certainly would be, since he was never a web engineer. In today's world of software engineering and web frameworks that allow for constant automated testing, Jamie Zawinski and his opinions in this area are completely irrelevant.
I have no doubt that he worked like hell while working in "Netscape Time", but I would wager a lot of the code produced by everyone working under those circumstances was garbage.
The very last statement, in Joel Spolsky's writing "The Duct Tape Programmer", you will see this:
They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.
Now, the following "good enough programmers" and "smart enough" is the only thing that really matters. Such programmers, can handle xor, as well as OOP (i.e.: inheritance, delegation, etc). So it’s not good enough to be a duct tape programmer, it’s being smart enough at your trade is what matters.
As a multiple inheritor, I've been forced by economic reasons to do duct taping.
It's great as long as you're the original coder, but if you're the maintainer it doesn't make any difference. Seriously. I've had to untangle both and I can tell you without tracing tools like XDebug or SQL query logs doing the job is next to impossible. But with these tools in hand, I got to cut down 6 months' reverse engineering into 1 week. Tracing works.
I agree with you, thanks for the post
Simpled code and automated unit tests go hand in hand. I don't understand Spolsky's fear of unit tests.
*I am by no means putting myself in the same league as Jamie Zawinski*
What? You're not jwz? But you have the same initials! And w's in your last names! This soo breaks my mental hash table for names :(
This is where I agree with you. Why can't one have simple codes?
Though I do understand that some people do this for two reasons probably. One is that they were trained and hard wired by their trainers to form complex codes even where there was no need to & secondly that the person to safe mark his territory did complex coding intentionally. I have come across some people of the second sort who do this as they were unsure they would ever be able to stay with the project till completion.
The result was dependence of the other people involved in the project on this 'complex' person till the projects went live !
Nonetheless it is the beauty of a code in the way it is presented in a simple manner.
