Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

Recently, I read some posts about Duct Tape programming from Joel Spolsky, Michael C. Neel, Jak Charlton, “Uncle” Bob Martin and Jeffrey Palermo. I have followed these posts closely. While the intent is good, I think the delivery suffers.

The whole thing started with Spolsky (as it often does) creating a post that (I think) was meant to say, “Hey stop pontificating on sweet new techniques and start shipping software!” Excellent point. Do that. Don’t worry anymore what other developers might think about the code you’ve written, or you developer “Image” and start delivering business value. Spolsky’s Duct Tape Programmer uses Duct Tape and WD-40 to get the job done, and it reminded me of another archetype I’d been exposed to earlier in my life.

The Backyard Mechanic

The Backyard Mechanic, if you’re not familiar with the term, is a term used to describe those guys who have been aroundchevy_350 cars all their lives. They rebuilt their first Chevy short-block 350 at age ten, and have always smelled like axle grease. I like these guys. With the exception of the rebuild, I am one of these guys (it was my Dad’s Ford 302 and I was 13). If I am ever broke down on the side of the 395 between Barstow and Tahoe, I want this guy riding shotgun. He will get me to the next town. He will make sure I get there. But I would NEVER pay these guys to work on my car, not even myself. Why? Because the “Git-R-Done” tips and tricks they use are simply patches. They know how to compress a brake caliper with a crowbar and a piece of wood, but a brake tool work much better and won’t run the risk of breaking (no pun intended) your knuckles if your hand slips. If I am overheating because of a leak in a radiator hose, I can put duct tape on the hose and piss in the radiator to get me to the next town. But I certainly don’t want to run my car on piss & Duct Tape on a daily basis. I guess my point is, when people PAY you for a job, they expect quality. They also expect you to get their car fixed as soon as possible, and I guess that’s Spolsky’s point.

Ship The F___ing Thing!

In Jak Charlton’s post, he talks about the alignment of business and IT and, to me, that is a more important point. In the “Project Triangle”, (Time, Quality and Functionality) you can only focus on two sides at once. The point is, it is not up to IT to make those decisions; it is up to the business. Developers need to align their development goals with the business goals of their customer. It sounds obvious, but it doesn’t seem to happen as often as it should. If the business decides to focus on functionality and time, the programmers should focus on functionality and time as well. But the business should be making an informed decision when they decide to let quality slip. They should know what it means to let quality slip and THEY SHOULD DECIDE that quality is less important than functionality and schedule. They should be made aware that the second version of this product might require a complete rewrite (let’s hope not), but they should be aware of that and walk into that decision informed and with their eyes wide open.

Quality Saves Time (And Not Just In The Long Run)

CalipersNMicrometer This doesn’t mean scrap the idea of quality programming all together. What it means is that, given the choice between time, functionality and quality, time and functionality win and we understand quality may suffer. From what I’ve seen, quality software actually saves developers time. Now, writing fifteen layers of abstraction and creating a new development framework for your project does not constitute quality. That’s architectural masturbation. Following the SOLID OO programming principles at the very least can certainly save you time, and not just in the long run. The fact that quality code is easier to change and enhance, means that as you build feature 2, 3 and 4, it will be easier and easier to do without having to re-factor chunks of existing code to do it. Techniques like Test-Driven or Behavior-Driven Development were developed out of a need to deliver software quickly without letting sacrificing quality. When done correctly, not only does TDD speed things up, it gives you a low-level regression suite that helps you ensure you didn’t break anything WITHOUT having to go manually test everything again (a MAJOR time expenditure). ORMs save a tremendous amount of SQL writing, not because it’s hard to do, but because it’s time consuming, and if you’re looking to ship fast without sacrificing quality, a battle-tested ORM (like NHibernate or SubSonic) can be a great fit. Finally, quality saves time just be cutting re-work. Doing it right the first time, means you shouldn’t have to go back and redo it a second time, which should save you time as well. All this is real time savings in the first version, not some hopeful future-vision of time savings down the road.

Quality Is A Requirement

Ultimately, quality should be a customer requirement. I don’t mean as in it’s required, I mean as in the customer should specify the expectation of quality. When gathering requirements, it might not be a bad idea to ask, “..and how high should the quality be?”

It sounds like a dumb question, and it will need some qualifying when you ask it, but it can help. Telling the customer about the project triangle, if they don’t know about it, and explaining how each side influences the outcome of the project can be invaluable. The way I tend to breach the subject is, “If I am building software for an EKG machine, I probably need to ENSURE the highest quality, even if it takes a while, but when building a corporate website, if the outgoing email from the contact us form says ‘Thanks for your fedback’, no one is going to die.”

If you don’t make the customer specify which side of the triangle is the least important to them and help them understand what letting each one slip means, you’re telling them you’re going to deliver 100% on all three sides, and your project is doomed. For the most part, businesses understand what letting the timeline or the functionality slip means, but as developers we need to make them understand what letting quality slip means to them. Otherwise, they will not understand why it takes you twice as long to make changes to the codebase after version one, if you don’t.


I guess my biggest point is don’t start by sacrificing quality. Duct Tape and WD-40 are awesome tools and every developer (and mechanic) should keep some in his toolbox. But that shouldn’t be the first tool you grab. When time and functionality are the most important things, I would start by looking to tried-and-tested tools (like an ORM or a scaffolding framework) to help get thing delivered quickly without sacrificing quality. Then once you have exhausted all of those avenues, reach for the Duct Tape to limp the thing home (until you can fix it properly).

That’s all of my rant for now. It is my opinion, I am entitled to it, and dog-gone-it people like me.

Posted on Saturday, September 26, 2009 10:58 AM | Back to top

Comments on this post: The Backyard Mechanic

# re: The Backyard Mechanic
Requesting Gravatar...
Hmm, nice reply to Spolsky. It almost always comes down to this: "cheap, fast, cool : pick two".

But I disagree at one point though. Asking the customer about quality is not a good idea. Its like asking them do you want a good software? Hell yeA!. And also, its implicit to the customer that quality will be there. A lot of software quality attributes have to do with the development team solely. For instance, I can code a command interpretter type of thing with duct-tapes, or i can use the design pattern. If the client never comes back to me, it doesn't matter what quality of command interpreter it really is. But this will really hit me back when in next release the customer comes to me with a 100 new commands and change to the previous 20. Had i implemented the design pattern there (from my experience) it could have been a breeze.
Left by Zaki Shaheen on Sep 29, 2009 1:46 AM

# re: The Backyard Mechanic
Requesting Gravatar...
Asking the customer directly about quality is probably not the right way to do it. But I understand Lee's point, and there has to be a tactful, professional way of feeling out the user's expectations and how they line up with 2 sides of the "Project Triangle."

Great post! I think it's been the best response thus far on this recent debate. I am glad I subscribed to the RSS feed, please keep your great content coming.
Left by Mike Murray on Sep 29, 2009 12:35 PM

# re: The Backyard Mechanic
Requesting Gravatar...
@Mike & @Zaki: THanks for the responses. Great debates on this topic. It makes us all better programmers.
Left by Lee Brandt on Sep 29, 2009 3:19 PM

# re: The Backyard Mechanic
Requesting Gravatar...
The fact that TDD leaves you with a regression suite is what first attracted me to it. I don't follow a strict TDD approach, but I develop automated tests as I go using my own approach. Being able to click a button and know a few seconds later if I've broken anything more than makes up for any time I spend putting the suite together. And writing the tests at the same time I write the code just makes sure I actually do so!
Left by Gene DeClark on Nov 03, 2009 12:26 PM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: