As in Dijkstra‘s quote above, when people criticize Quick-and-Dirty programming they are in general focusing on the negative impact in the system being developed. Software that is built following a Quick-and-Dirty approach will certainly have some serious deficiencies, which are also called Technical Debt.
However the Quick-and-Dirty approach has a different consequence that is as important as its violation of software design principles: It destroys the morale of the development team. Programmers should be proud of their work, but when they adopt Quick-and-Dirty solutions they are sacrificing their own professionalism.
In one of my first posts in this blog, I claimed that “Nothing is More Effective Than Enthusiasm“. The idea is that the best programmers are always enthusiastic about their work. But working Quick-and-Dirty is actually an enthusiasm-killer. Eventually the developers will become so disgusted with the system they are building that they will prefer to leave the project than trying to fix it.
Doing It Wrong
Besides the suffering caused by intentionally creating a bad product, programmers constantly working in Quick-and-Dirty mode will never have the opportunity to gain experience, improve their skills and actually become professional software developers. As in the quote by Frank Sonnenberg:
“Practice doesn’t make perfect if you’re doing it wrong.”
Worse yet, working Quick-and-Dirty may become a habit. In this case the poor and simplistic solutions may be chosen even when there is enough time to implement a proper design and avoid the creation of Technical Debt. Instead of being an emergency solution, Quick-and-Dirty may become the standard approach.
Unfortunately I think this phenomenon is very common in Agile projects: Programmers are motivated to adopt Quick-and-Dirty solutions to increase their own Velocity and display more progress in the Burn-Down charts. I discuss that in my article “The End of Agile: Death by Over-Simplification“.
In conclusion, if you are a software developer currently working on a project in which most of your work is Quick-and-Dirty, I seriously recommend you should consider finding another job, either in a different project in your company or in another company. Good luck!
What do you think? Do you agree? Please share your experience in the comments below.
Effective Software Design 
I agree that NO respectable profession can have the policy of “QUICK-n-DIRTY work as its standard”.
However, experimentation, rapid prototyping, quick-n-dirty trials of concepts / solutions etc., should NOT be eliminated altogether.
Agile Approach making Quick-n- Dirty practices as THE preferred policy is certainly unprofessional and worth condemning.
25OCT15
Agreed, including on the final suggestion: though, as for who is responsible for what, the emphasis should definitely be on managers, not on developers: professional (real) developers indeed know better than anyone else what a self-destructive practice that is, and, in fact, how compromised the situation overall is across our industry.
I agree that a major main drive for doing poor quality job comes from managers, who would like to see the job done and are afraid the developer is wasting their time on unnecessary professional perfectionism.
DeMarco advised how to approach such management. I don’t remember the exact phrasing, but it went along the line of “If you don’t have the time to do it right, then you certainly don’t have the time to do it wrong!” (Doing it wrong always takes longer, in the long run…)
Oh yes, that is how it is, though there is not yet a remedy there: IMO the remedy goes along the lines of “recognising where the competence is for what”: I mean, literally, a wake up call. E.g. who would you appoint to run production at General Motors: a mechanical engineer, a theoretical physicist, or a marketing specialist? The answer to *that* question is immediately obvious, yet when translated to the software arena, something opposite happens, despite (or, maybe, all the more so because) software production in fact entails the most complex engineering that there is…
Quitting is not an option, fixing is! And I’m not talking about fixing bad designs. Rather, if you are a smart guy who see in depth the problems and solutions of the project, be also wise and show a better way of working efficiently. There are a lot of means to do it. Patience is one. There is more at stake than your own working happiness, and there is a lot of learning, too.
Thanks for your comment, Bogdan. The possibility to fix problems depends on many things, such as the company’s culture, the project’s deadlines, and the support from other development team members. But I agree with you that if it is possible to fix bad practices we should try it instead of quitting.
I don’t really see what Agile has to do with a “Quick and Dirty” approach. If people are interpreting Agile as a call to embrace this approach then that is incorrect. Velocity and Burn Down charts are not prescribed by Agile, they are project management tools.
Agile is a mindset that should help build quality (delivering real value as determined by the customer) into software. Ultimately the responsibility rests with the developer who has the call whether they right the code in a professional manner, or agrees to do a bodge job.
Thanks for your comment, Steve. I agree that Agile is a mindset, but in practice most people are following Scrum, measuring their Velocity, drawing Burn Down charts and working in extremely short Sprints that very frequently don’t leave enough time to do a proper work on all User Stories.
This is complicated, I find, because the definition of “quick-and-dirty” is very subjective, and the lifecycle of software, as well as the psychology of both programmers and their clients or users contributes to the problem.
The best analogy is that of the chef vs. cook. Anybody who makes food professionally can be a cook. If they live in a small town in the middle of nowhere, their customers don’t have high expectations. The cook can make scrambled eggs that are dry and “acceptable”. In the city, the same cook may need to up their game and make them a bit fluffier or they won’t get a job. They cater to the market that surrounds them, and getting the job done acceptably is all they care about.
A chef is different. Regardless of whether they are in the outback or in the city, they not only want to create good scrambled eggs, they want to be inventive, use the best ingredients, and even make them cost effective (good chefs know how to factor in economics). A chef is not so much as artist as a “full stack” food engineer, who knows how to create a successful menu that delights the customer and grows the business.
I have worked with many programmers who approach to their work is like the cook, regardless of methodology. If a test is a throwaway, they will do the minimum. If a client is not paying well, they figured that you get what you pay for. If the client says do it this way today, and doesn’t think ahead, it’s the clients problem (not the programmers) if needs change and two years from now the code written today becomes a mass of spaghetti. Agile is an excellent tool for the cook because it puts this “good enough” mentality into a production environment where course-corrections and errors are factored into the development model. You iterate and release quickly because you know you’ll be wrong. And the more quickly you expose it, the more quickly you can correct it.
There are very few chefs in software. Why? I believe this is because most programmers are not well-trained. Many are self-educated and cannot tell the difference between an opinion about software and a fact about software, so they are susceptible to a great deal of misinformation online, and fads which come and go.
Few programmers have built complex systems that require genuine architectural invention and the management of complexity. As a result, terms like architecture, OOP, rapid-prototyping, etc. become buzzwords that people flock around (and often misuse) rather than simply tools in a broad toolset which can be applied freely when desired. We are seeing this now with “micro-services”… a simple concept of interface-driven design that has been around for 40 years has become a new “manifesto” of design. So, people don’t really understand the importance of interfaces, they don’t understand the reasons why micro-services can sometimes be good, and sometimes be bad, and create systems which are difficult to maintain and become obsolete quickly because they blindly embrace this new buzzword.
I think it is actually possible to create software quickly that is not dirty. In fact, the more reusable components there are, and the more resilient interfaces are, the faster software development becomes. But, people don’t do this, because they don’t have the individual, or team, skills. And, we don’t seem to educate programmers as chefs, but as cooks.
So, to me quick-and-dirty really means quick-and-beyond-my-ability-to-do-this-right. Never a good thing, but what we seem to be cursed with because of the lack of deep understanding.
Thanks for your comment, Gary. I like your analogy of chef vs. cook. I think that, unfortunately, in software development today we have too many cooks that don’t have any aspiration of becoming real chefs. It’s easier to find cooks that want to become the managers of a restaurant, or the owners of their own restaurant. Many of them don’t see themselves cooking in five years from now.
Pingback: The Problem with Velocity in Agile Software Development | Effective Software Design