Smart and gets things done *right*

I suppose it’s time for the obligatory weigh-in on the latest bit o’ reckless software advice from Joel Spolsky on the merits of the “Duct Tape Programmer”.

I think being a duct tape programmer is a bit like being an alcoholic. Once you become one, you are one, and when you want to stop, you have to constantly be vigilant against backsliding. Oh, and the first step is admitting you have a problem.

Hi, I’m Scott, and I’m a recovering duct tape programmer.

I don’t want to get too deep in the weeds on Joel’s article, because the simple fact is that it doesn’t warrant as much discussion as it’s getting. On further review, he doesn’t say much more than “be like this and get things done, but, you’re probably not smart enough to be like this, so…”. I will be pulling out a few key parts of his article to make my points however.

What I do want to talk about is this notion that somehow being a craftsman and striving for appropriate, maintainable, and dare I say elegant solutions is in opposition of getting things done.

There’s a major problem in this industry (and the sub-industry of blogging/speaking/writing about this industry) of trying to remove contextual analysis from what we say. When we do that we get ourselves in trouble. Every product is different, every organization is different, and the needs of each varies wildly. Therefore it’s impossible to prescribe one action over another free of context. The second side of that same coin is that the vast majority of people taking this sort of context free advice don’t recognize this lack of context and run with it because some hero they worship said it. Then you get people that say things like “I don’t want to write tests because Jeff Atwood and Joel Spolsky don’t” or “I just want to code all night in a cave and ‘get shit done’ because that’s what Joel said is valuable to business”. This is a major problem.

There’s also this problem of the definition of “quality” in software. Some people tend to take a narrow view that the software quality issue is about patterns and clean code. This is part of it to be sure, but it’s not the whole thing. Quality is part of solving the problem. Solving the right problem, with the right solution, that works for the business, in an amount of time that ensures value was provided, that’s part of quality. Ensuring that the code is at the very least *correct* is also part of quality. Ensuring that code is maintainable can also be part of quality. Each of these parts of quality has a cost associated with it, and business decisions have to be made about the ROI tradeoffs associated. The problem is the business rarely makes the decisions, because the developers either don’t care to raise the issue and educate, or don’t want to.

Joel’s hero of the day was Jamie Zawinski, one of the original developers at Netscape. He stands him up as a bastion of getting things done, and I won’t begin to deny Jamie’s talent. But I do want to break down the straw men set up by Joel and add some context.

Just what is “important code”?

Remember, before you freak out, that Zawinski was at Netscape when they were changing the world. They thought that they only had a few months before someone else came along and ate their lunch. A lot of important code is like that.

Yes, that was back in the glory wild west days of the internet and in the formative years of what the software industry has become. And yes, a lot of people are under the gun to get something to market before their funding runs out or someone bypasses them. But let’s be real. The vast majority of software development out there is on the more “mundane” systems…you know…the ones that run the world, rather than the fancy Web 2.0 products. Do you want a duct tape programmer writing the software that controls your bank, or the lab equipment processing your mother’s biopsy, or your insurance company’s claims system or the air traffic control systems? I don’t know the numbers, but I’m willing to bet that more people working in corporate IT on systems that have real impact on lives read Joel’s blog than do people like Jamie. Just a guess.

For me, the code running my bank is more important code than web browser code. Calling it “important code” is a huge red flag for me of the developer/geek bias in Joel’s opinions. Important in this case means approximately “cool and new”. My definition of important code makes me afraid that the people who write such code will follow Joel’s advice.

Ship It!

“Yeah,” he says, “At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

Yes, you’re here to ship. I don’t think that’s a question in anyone’s mind. But let’s talk about the meat of this quote. The assumption here is that the developers of the non-duct-tape variety are focused on “pretty” code. Coupled with other sentiments in the article, it would seem that Joel (and Jamie) is saying that a testing practice and the idea of putting together a readable, maintainable codebase is the enemy of getting things done. This isn’t a binary issue. Being for a maintainable codebase doesn’t mean being against shipping. Being for code quality doesn’t mean being for cleverness or complexity for the sake of cool (quite often it means the opposite).

Again, this statement lacks the analysis of the context of different project and organization needs. If you’re trying to produce the world’s first web browser then yeah, get it out there and get it done. If you’re trying to produce a long-lasting insurance claims application that will be the backbone of a corporation’s business, then maintainability should probably be on your radar. Again, include the business in the decision making process. You shouldn’t go off on your own in either direction, sacrificing quality for speed or vice-versa.

Testing

Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go.

Now this is just crap, and it assumes and perpetuates the flawed idea that a mature testing practice costs you time. Yes, I said mature. Getting started on TDD will be slow at first, but the payoff is huge. And let’s not forget that time to market is total time to market, not just time to code features. Those features have to be implemented and tested before release (hopefully), and a practice that eschews testing for the sake of speed is often going to result in costly rework that will cost time ultimately. Again, context being what it is, I’m not saying that you can’t do quality work and avoid rework with no testing, but what I am saying is that you also can’t say that testing is only for those with “a leisurely development pace”. My team cranks out features at an alarming rate sometimes, and manages to do so while practicing TDD and testing all the way up and down the stack.

The point I’m getting at here is that we need to evaluate each project on its own merits and decide the practices that are appropriate to produce the value needed in the time required, and that we absolutely have to be careful about tossing around potentially harmful advice to our large audiences that will likely lead to some really crappy software being produced. Matt Hinze said it best when he said “…never take software advice from a bug tracking system salesman”.

Oh and let’s not forget how bad Netscape’s browser ultimately became, and what a bloated piece of garbage it was by the time it died. Guess all that duct tape caught up with them.

Technorati Tags:
, , , ,

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Scott Reynolds

Scott C. Reynolds is a developer with over a decade of experience creating enterprise solutions, primarily in healthcare and biotechnology. He is passionate about the art and craft of applying software solutions to business problems. He is a frequent speaker and participant of community events nationwide.
This entry was posted in rant, software, testing. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

25 Responses to Smart and gets things done *right*

  1. jdn says:

    “Oh and let’s not forget how bad Netscape’s browser ultimately became, and what a bloated piece of garbage it was by the time it died.”

    Look up the history. That isn’t the code Zawinski worked on.

    Out of curiosity, what are the codebases that you can point to that prove what you say about TDD? I mean, since you are better than Zawinski and Joel, you should have a long list of all the successful things you’ve produced.

  2. @jdn

    some things never change eh?

  3. Stephen Smith says:

    Responding to Joel Spolsky posts is akin to responding to Nigerian email scams.

  4. Aquaren says:

    Amen

  5. Lee Brandt says:

    NIce post. While I disagree with just about ALL of Joel’s post, it started a great conversation in the community. It has lead to discussions about WHY quality is important and WHY duct tape is bad. Excelent point about the banking systems.

    ~Lee

  6. Steve says:

    I think jdn does make a valid point actually. Joel owns a software company and a moderately succesful website, that’s more than most people who have said he’s wrong.

    I’m not saying I agree with everything in Joel’s post either, since let’s face it, he makes money off of bugs, but he does make a fair point of the Astronaut Architect v. the Duct Tape Programmer. More often than not in the .NET world, I see developers come up with overly complicated solutions to what should be simple problems.

    I did a few side projects in RoR which practically forces you to make your design simple and streamlined and it was nice to know that the team would have to go out of your way to over-engineer it. In C#? You have to be vigilent because before you know it, someone’s added some over-engineered piece of junk.

  7. Scott Koon says:

    OK JDN, I’ll take you up on that. You asked for production code that used unit testing.

    We unit tested the JupiterImages.com site heavily. We also created integration and scenario tests. The unit tests ran with every build, which kicked off on every check in. We migrated over 200K users from the old production site,which included all their cart and lightbox data from an entirely different data schema. We created automated migration tests that logged in as each user and tried to weed out any possible bugs caused by the migrated data. We found them and fixed them way before our lauch.

    I was on the production support team after our launch for 4 weeks. Most of the work we did related to adding new collections into our site rather than fixing bugs. All 12 of our team members were required to be on call 24/7 for a week starting with our closed beta launch and running through production support. NO ONE ever got a call. I attribute that to the disciplilne of the team members and our use of automated testing, both unit and integration.

  8. Mark Brackett says:

    > Then you get people that say things like “I don’t want to write tests because Jeff Atwood and Joel Spolsky don’t” or “I just want to code all night in a cave and ‘get shit done’ because that’s what Joel said is valuable to business”,

    Really? I don’t really believe anyone who knows of/reads Joel’s articles is stupid enough to say those things. But, even if you could find your mythical strawman – that just proves they’re an idiot.

    I don’t think Joel needs to couch all of his advice with disclaimers about how “getting things done” doesn’t mean doing a shitty job. Any half-wit should be able to figure that out.

  9. @Mark
    I’ve heard it from plenty of people. I think you’re forgetting that there are a lot more people in this industry who don’t do that analysis to understand that what is being said by a “celebrity” isn’t meant to be globally applied without question. That’s one of the points I made above.

    @steve
    if that was jdn’s point I missed it. Nowhere did I say I was better than anyone, and went out of my way to point out that Jamie in particular could code circles around me with his keyboard behind his back. It doesn’t change the point that it’s not an either/or proposition, and that the statements, free of context, lack a lot of merit.

  10. Steve says:

    @Scott,

    Well maybe I missed his point then. He wrote:

    “Out of curiosity, what are the codebases that you can point to that prove what you say about TDD? I mean, since you are better than Zawinski and Joel, you should have a long list of all the successful things you’ve produced.”

    Basically calling out anyone who uses TDD to demonstrate that it will produce better software.

    Now, I have no idea where you work, what sort of code you write or anything like that. So this isn’t in anyway directed at you, but I do find in these types of arguements that the person yelling the loudest (again, not talking about you) has the least practical experience with the subject matter.

    I like Alt.NET, I think it’s made me a better coder, but when I read blogs/posts where the claim is that if you don’t follow X, Y and Z (let’s say SOLID, TDD and IoC, but we could insert anything else) that your code is doomed to be an unmaintainable ball of mud it makes me laugh. There is bucketloads of software out there designed by good coders who didn’t follow every tenent of the Alt.NET manifesto, yet their code works just fine. Am I supposed to discount all this factual evidence just because some guy who works for some company I’ve never heard of and has 18 Twitter Follower says so?

    Again, I’m not defending Joel’s article because, but I don’t think it was nearly as bad (or damaging) as others believe. But right now, the people talking TDD are those selling books, how many of them are designing “top level” software used by millions of people? It’s a valid question.

    Then again, if that’s not what jdn was getting at, well then I’m lost. :)

  11. @steve

    jdn is a useless troll, you just may be lacking the historical context to know that. When he says something that merits response, I’ll do so.

    As to the rest of your comment, I’ll make you a deal. You’re fairly anonymous right now, I don’t know you, and I honestly can’t tell if you’re just trying to push my buttons or if you’re asking honest questions.

    If it’s the latter, I’m glad to respond. Probably in a new blog post.

  12. Steve says:

    @Scott,

    I assure you, I’m not trolling, but these are questions that I’ve been asking myself since I read that article by Joel. Actually, check that, it wasn’t so much his article, but more the responses to the article that have me thinking.

    I spend most of my day driving home to a group of developers that SOLID, Unit Testing, IoC, etc. are all Good Things(tm). I still think they are, especially SOLID since it makes the code so much easier to read, understand and maintain. So I’m in no way quesitoning whether or not that those are bad things to be teaching my team. It’s more the difference between the “get it done now” v. the “get it done ‘right’, but later” approach that is now being discussed.

    I think we’ve all seen how poorly implemented and thought out code in the name of “getting it done” can cause problems down the road, but lately I’m seeing problems with the “get it done ‘right’, but later” approach as well. I see needless refactoring of existing working code, all because that working code was done “wrong”. I see simple problems being solved (or more accurately, attempted to be solved) with unnecessarily complex solutions and it’s got me scratching my head. If I ask for a website that has one page to just display two or three pieces of data, if I don’t stay on top of it I’ll be delivered a solution using WCF to contact a full blown DDD midtier using NHibernate and memcached.

    I try and teach my guys (and girls) how to be better developers, but I think where I’m lacking is teaching them when to use these new skills and how to apply them succesfully. I can’t remember if it was Ayende or Karl Seguin who wrote a blog post a last year about JFHCI (Just F’n Hard Code It). Sometimes a full blown Pub/Sub system with a custom rolled Rules Engine fits the bill, but sometimes just putting a True/False value in a config file does the job just as well (a real life example that I had to deal with recently). I hope we (as in all of us) don’t forget that.

    I wasn’t aware of jdn’s trolling nature, but I think there is a good point in there somewhere. At my office we’re debating the move to TDD (we’re currently TAD), and I wonder if it’ll produced better code or not. I’m told it will, but I haven’t really got any proof. I’ve never heard anyone say that “Product X, a clear market leader uses TDD and that’s why they are so successful”. I’m a firm believer that by far the single most important factor to developing good or bad code sits between the chair and the keyboard, everything else is secondary…sort of a silk purse/sow’s ear sort of thing. So while I’m quite sure that ignoring everything I’ve learned would be a horrible idea (there’s a reason the DailyWTF.com exists after all), I’m wondering at what point is it more about getting good people to do the best they can v. the process.

    I hope that clarifies what I’m getting at.

  13. Scott Koon says:

    Steve:

    If you’re not sure if TDD will help or not, try it out. Take an existing method or class in your code base and try to write tests for it. See if you can weed out all of the hard coded dependencies so that you don’t have to use a lot of mocks in your tests and then look at the code and think about what it would take to swap out or change one of the dependencies. See what it would take to break your tests, try changing your code and see if your tests break.

    Honestly, that’s what sold me on TDD. Trying to test an existing method. It really helped me to see where all my dependencies were. I don’t/can’t always use TDD, but even when I’m not I want to and try to make sure I’m not writing garbage.

  14. @steve

    not get it done right, but later. get it done right, now. This is the meat of my point above about TDD (and applies to the rest). Just because you have a timeline doesn’t mean you need to skimp on practices you believe in.

  15. @steve

    I’m working on a few responses. Stay tuned.

  16. Steve says:

    @ScottK,

    Pretty much all of that is applicable to TAD (not to mention BDD or what Ayende is calling “Scenario Testing”).

    We have an extensive Code Review process, we teach all the goodies (SOLID, DRY, YAGNI, etc.), we have Unit Tests and while I feel that “forcing” all of that on bad developers can make them mediocre (or at least not so damaging), I don’t really know how much they benefit a good or great developer (well, for one they probably are doing most of it anyways).

    So I take a top 10 percentile developer (in skill, knowledge and the fact that they just “get it”), and move them from TAD to TDD, am I really going to see an improvement?

    I don’t want it to seem that I’m questioning only TDD, because really I’m not. Substitute TDD with DDD, BDD or any other achronym and I’m asking myself the same question. What is the ROI that this process will give me? If it’s high, where’s the proof?

    I think back to bar-none the best product I’ve ever developed, and realize that it was built in a .NET 1.0 (upgraded to 1.1 during development), we had a pure Waterfall environment and we didn’t even think of building any Unit Tests. But we churned out a product that not only is still widely used today, it’s also customizable and used by about 50 different customers (completely rebranded for each with incredible easy). It was a smashing success and made the company we built it for a crap load of money. What occurs to me now (years later) is that the reason it was so successful is we had a rock solid team, everyone single person could have been a lead on any project, but we all came in and accepted our roles and di d our job. But if I looked at that code today, I’d probably throw up. I’d find all the problems with it and want to refactor it…but the question is, why? The code not only works, our customers loved it…I mean, loved it. So much so that they don’t want a new version even to this day a good 6 years later. From what I understand, my old companies have done tweaks to it, but they’ve wisely resisted the urge to re-design it from the ground up just because it’s old.

    To me, that is the probably the only point worth taking from that Duct Tape Programmer article. It should be about producing software, not about a software process (be it Agile, TDD, XP, Lean, or whatever comes down the pipe next year) and to me, the best way to do that is hire good people.

  17. Steve says:

    @ScottR,

    >not get it done right, but later. get it done right, now. This is the meat of my point above about TDD (and applies to the rest). Just because you have a timeline doesn’t mean you need to skimp on practices you believe in.

    I agree, but I’m curious as to why we believe them. SOLID, DRY, YAGNI and some form or Testing (Unit, Behavior or “Scenario”) to me are no brainers. I see the benefit from all of those on a daily basis because the code is more readable, easier to understand and more maintainable. So I’m in no way telling people to hack up crap.

    But at the same time, when it comes time to design something new for a small project and suddenly I’m looking at an architecture that is better suited for an enterprise application, that is where things get a bit fuzzy. If something is small and dinky, a 10 minute job that just needs to be done to keep a client happy, I don’t want my developers to start cranking out Repository Patterns, coming up with new architectures using the “latest and greatests”, etc. I just want them to fix the problem (but adhere to things like SOLID because I honestly feel that those processes don’t add time to development).

    At some point, I feel that we’ve (meaning the C# Community) abandoned KISS in favor of a lot of other buzzwords. I guess that’s my overall point, I appreciate you humoring me. ;)

  18. @steve

    short answer: we believe in them because we’ve taken the time to evaluate, learn, and apply them, and seen that they work. If you haven’t, then you aren’t in the same position.

    see my latest post with regard to the rest of your comment. if you can point out where I’m preaching overcomplication, I welcome it, because I don’t think I have.

  19. Steve says:

    @Scott

    I’ll take a look, but I never said you specifically preached over complexity. I repeatedly said I my concern was with the C# Community as a whole.

  20. jdn says:

    “jdn is a useless troll, you just may be lacking the historical context to know that.”

    LOL. I reject the label ‘useless.’

    It’s nice you don’t actually answer my question.

    There are many, very successful programmers who don’t use TDD. In fact, numerically speaking, a lot more than who do use TDD. Unlike you, they are well-known and have public recognition. Although the numbers are changing, the VAST majority of successful, well-written software wasn’t developed using TDD.

    Given that, why should anyone listen to anything you say? Because you claim that your work is better with it? That’s confirmation bias.

    Plus, anyone who knows anything knows that TDD *sucks* and you should be doing something like BDD.

    Anyone interested can click and see my blog and my ‘trolling’ including how I advocate following SOLID principles, etc.

    The fact remains, Joel and Zawinski know more about software development, and have proven track records, than some LosTechie blogger.

  21. @jdn you’re invited to not read an comment on my blog, as I’m just some LosTechie blogger without a valid opinion.

    kindly gfy.

  22. @jdn

    I didn’t answer your question because it wasn’t directed at me. It was clearly directed at somebody that you heard say things that you are misattributing to me. I don’t intend to play your game.

    If this post were about TDD (it isn’t), and if I said that TDD is the only way to develop good software (I didn’t), and if I said that only bad programmers don’t use TDD (I didn’t), and if I said that I was better than Zawinski (I didn’t) then these kinds of comments *may* be warranted.

    As it stands, I refuse to engage in a debate with someone who, despite having 15 PhDs or whatever, doesn’t seem to have leveled up his reading comprehension skill very much. Either that, or you’re a useless troll. You either intentionally are trying to pick a fight about things I didn’t say in the post, or, you didn’t read and understand the post. Your pick. Stupid? Or Troll? What’s it gonna be? Which one fits you better? It’s one or the other. Either you got those PhDs by mail order, or you’re a troll.

    Personally I don’t care which one it is. Come back when you grow up and want to engage in real discussion. At present, however, your past interactions with myself and others, and your comments here, give me no reason to treat you as anything but a troll…or…I guess if it turns out you’re not really that bright after all, I’ll feel a little bad for being so mean. But don’t worry, I won’t spread it around that your PhDs came from a Cracker Jacks prize pouch.

  23. jdn says:

    LOL.

    “Do you want a duct tape programmer writing the software that controls your bank, or the lab equipment processing your mother’s biopsy, or your insurance company’s claims system or the air traffic control systems?”

    Duct tape programmers did probably in fact write the software for all of these. Not to mention things like the software for the Apollo space missions, etc.

    There’s no ‘game’ here. Some people without a lot of credibility to back them up like to talk about quality and maintainability and simply ignore the history of software development.

    “Getting started on TDD will be slow at first, but the payoff is huge.”

    It can be, sure. It can also be a disaster.

    “Matt Hinze said it best when he said ‘…never take software advice from a bug tracking system salesman’”

    Oh, how droll, how witty. Not a troll there at all, nope.

    People would be better off taking advice from Joel than others.

  24. Josh says:

    My two cents, if its worth two, is this.
    I’ve done TDD, waterfall, no spec, post card spec, cowboy coding, etc. All done through classic asp up to .net 3.5. Classic ASP was just horrible to code in. It worked though, and got a job done. There was even times when changes were done on a production box! Would I ever do that again, yes. The 6 pages for my dad’s website doesn’t need TDD, a full documented spec. Would I do that for the project I’m working on right now, heck no!. I’ve unit tested anything that adds two numbers together, has an If statement somewhere. All my crucial code paths have unit tests. They are small, simple unit tests because my dependencies have been handled nicely from the start because of TDD.

    I think the main thing to take away from this internet discussion about “duct tape programmers” is this.

    Don’t write code you don’t need, don’t write code because its cool. They have a name for that, pet projects. Don’t write some crazy encapsulation layer that only you and one other person in the world can understand, maintenance at 2 AM will kill you for that. Also, be agile in the approach you take, something might work for one project but not another, adapt to the changes between projects. There is no definitive right way for what we do, just do the best you can do at that moment, for that project, and the foreseeable future.

    Again, just my two cents.

  25. @josh

    That’s a fair and pragmatic view