I’ve been meaning for some time to write about how slow “quick and dirty” is, how misnamed the term is, how misguided are the hoards of managers (many of them former and current software developers) who embrace “quick and dirty” as a fast solution to pressing problems, as though it could ever deliver an actual solution.
I’ve been meaning for some time to write this. It took Lidor Wyssocky’s latest blog post to push me into it. And just in case someone out there couldn’t tell you were joking… (You were joking, right?) The sad truth is that “quick and dirty” may be dirty, but it’s never quick, at least not if you actually want to deliver a usable product.
“Quick and dirty” never has all the features the customer expected. And it rarely will. Because when you try to support all those edge conditions, the complexity quickly overwhelms you. It takes you twice as long to add the code to support the edge conditions, and in doing so you introduce innumerable new bugs.
“Quick and dirty” is what the A-Team did to build a tank out of a truck or a jeep. Yeah, maybe it got them out of their current predicament. But 5 minutes later, the whole landscape was in ruins (including the tankified vehicle). Is that what you want to deliver to your customers? I’m going to guess “Not.”
Pam Slim in an interview talked about her some of her early consulting clients:
As your readers know, “doing the right thing” in corporations is not often supported, especially by senior management. But I felt really passionate about spending their money and my time on things that were most likely to make a real difference. I turned away many clients who insisted that I do things that I felt would be counter-productive to their business goals…
… and in what situations should we as professionals allow ourselves to adopt quick-and-dirty? (You are a professional, right?)
The general rule I use is that if it’s a spike solution for proof-of-concept or one-time demo, it’s okay to do quick and dirty. Because these things do not get delivered to customers. Before I deliver proof-of-concept or demo code to a customer, I clean it up. Or I rewrite it. Because I know that doing it right the first time is going to be both better and faster than any other way.
Deep in the recesses of my memory, there’s a story about a software development workshop. (I wish I could remember the citation.) The developers who attended the workshop were given some programming problem to solve and a limited amount of time in which to solve it. Those developers that took a little time first to think about the problem and how they might solve it generated more reliable solutions in less time than their counterparts who just started coding.
(By the way, the opposite of “doing it right” is not “doing it quick.” The opposite is “doing it wrong.”)
This is a running theme on Mythbusters. Host Jamie Hyneman, faced with a challenge, thinks first before constructing a solution, always looking for the simplest, most elegant design. Co-host Adam Savage, on the other hand, plunges forward impulsively, with cool, clever gizmos and gadgets. They frequently do episodes where the two Mythbusters compete to construct a device that will do such-and-such. Guess who more often achieves the goal within the allotted time, usually with a solution that makes you go “Wow.”
All software designs have some necessary complexity. Good design manages this necessary complexity, dividing it into smaller, simpler parts. I had a manager, a practicing software developer, who occasionally would criticize me for always doing grandly architected software designs. This puzzled me. When I pressed him on the issue, he told me that I had introduced unnecessary complexity. But every design feature he complained about was something that would be there anyway. So I told him so. Then he hit me with what I believe was the real issue. He said, sometimes we have to get the software out there, and we don’t have time for grand architecture.
As a professional, how can I see eye-to-eye with such a man? I was not sorry for my architectural decisions. These choices even allowed us to deliver features we previously could not even consider. And I will always be proud of his negative review. Because I knew and still know, it’s faster to do things right the first time, rather than to do it wrong.
Or to put it another way: I’d rather be known as someone who actually delivers what he says he will when he says he’ll deliver it, rather than someone who does “whatever it takes” and then delivers something that doesn’t actually work.