173

If you ask programmers why they should write clean code, the number one answer you get is maintainability. While that's on my list, my main reason is more immediate and less altruistic: I can't tell if my new code is correct if it's too dirty. I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly. Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later." Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal? Is it a skill worth trying to develop? Or is a lack of confidence in the code something some people just find easier to accept?

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 43
    My theory is that all coders fall somewhere in between "memorizers" and "understanders", and few can do both well. The more crap you can remember at once, the more messy you can afford to make your code. Whether the code is clean or not, make it work, test it! – Job Dec 13 '11 at 16:05
  • 35
    _However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."_ heh... hell will froze before it's "_later_"... – Carlos Campderrós Dec 13 '11 at 17:10
  • 2
    All my 'quick&dirty' code throw an exception on unhandled case. This isnt a bug but i dont think i can ship with all of them... –  Dec 13 '11 at 18:23
  • 29
    Not all programmers think alike -- I've been given code to maintain that made no sense to me for months, until one day, it was like a light switch was flipped, as I realized what the overall organizing structure was, and it all made sense why they had done it how they did. Would I have done it that way? No, but it worked. – Joe Dec 13 '11 at 19:07
  • 1
    Not quite an answer, but I think it is important to distinguish between "quick & dirty" ("saving" time by being sloppy) and iterative programming (starting with the smallest possible prototype that barely meets one core requirement, then keep improving it until it's done). There is nothing wrong with iterative programming, but being sloppy is seldom a good thing. – tdammers Dec 13 '11 at 20:15
  • The important thing about iterative programming is that each little iteration should work really well. – DJClayworth Dec 14 '11 at 01:46
  • 12
    @joe -- +1 -- some programmers are too quick to dismiss code that does not fit into there personal idea of "good code". You should always try to understand the thinking behind a body of code and its code style, often you will learn something useful. – James Anderson Dec 14 '11 at 01:51
  • 1
    There is no answer to this question because its too subjective. Its like philosophy and religion. What is dirty code? What is clean code? What level of testing is considered dirty or clean? etc, etc. this has no answer other than providing a means of social grease for nerds. – Joonha Dec 14 '11 at 06:21
  • 11
    `How do quick & dirty programmers know they got it right?` Because it works :) – Rachel Dec 14 '11 at 15:21
  • 2
    I know it's right because I wrote it. – Wolfger Dec 14 '11 at 14:51
  • In my own experience, it is very frustrating and time-consuming to chase bugs in quick and dirty code that was checked-in two years earlier by a developer that does not work in the company any more. So, there is no perfect code, but each project should have some coding guidelines and code reviews that do not allow code below a certain standard to be checked in. – Giorgio Dec 15 '11 at 11:17
  • 1
    "Because it works" - for certain definitions of "works" – Joshua Davis Dec 15 '11 at 21:45
  • Good programmers can *sometimes* pass bugs or unexpected conditions as *"hidden features"*. I have done this, when the unexpected turns out to be the logical result after all. If customer does not like the unexpected 'feature', you fix it to his liking and move on. This does not change the amount of work, but really does make it seem (psychologically) like there are less bugs. Oh. And a habit I have is to use a very minimal home made test framework that holds tests to validate the main tasks in the scripts. – stefgosselin Dec 19 '11 at 20:29
  • 1
    Quick & Dirty Programmer = Someone more sloppy, or slightly less clever than me, who wrote code that makes me mad. – Warren P Dec 20 '11 at 20:07
  • @James Anderson: I agree and I think it makes a lot of sense to look at finished code and try to understand the thinking behind it before dismissing it as nonsense. In this respect, I think that a big downside of pair programming is that too many good ideas are dismissed as nonsense by one member of the pair before the other has the time to properly write them down into working code. This happens because it would take some time to really understand somebody else's thinking, whereas in pair programming everything happens very quickly. In this way, many good ideas simply go lost. – Giorgio Nov 20 '14 at 23:26
  • Why do you think it's called "dirty"? – Lightness Races in Orbit Jan 29 '15 at 10:55

21 Answers21

241

They don't. I'm currently working on a code base created by "quick and dirty" programmers who would "clean it up later." They're long gone, and the code lives on, creaking its way toward oblivion. Cowboy coders, in general, simply don't understand all of the potential failure modes that their software may have, and don't understand the risks to which they are exposing the company (and clients).

H A
  • 101
  • 4
asthasr
  • 3,439
  • 3
  • 17
  • 24
  • 32
    Whenever I hear the "clean it up later" or "we will do that when things slow down a little" I'm always tempted to start singing "Tomorrow, Tomorrow, I'll love ya tomorrow. It's always a dayyy awaayyyyy." That could be just me, though. – JohnFx Dec 13 '11 at 17:59
  • 1
    @JohnFx: Psychological warfare. I love it. – fluffy Dec 13 '11 at 19:03
  • 8
    Many of us have been in that rather unfortunate position. It's pretty dis-spiriting being bequeathed other peoples' [technical debt](http://en.wikipedia.org/wiki/Technical_debt). – Mark Booth Dec 13 '11 at 19:39
  • I would say that the company is not understanding the risk it is taking preferring (probably cheaper) cowboy coders to true professionals. – Paolo Dec 13 '11 at 21:46
  • Quoth the raven, nevermore: "Beware of bugs in the above code; I have only proved it correct, not tried it." A modern view if this would be "not tested it". Now the difference between the above and the programmers in the OP is that they didn't even take the time to prove it correct. But this alludes to the notion that even if you prove something correct, it doesn't prove that your code matches what you think you proved. – corsiKa Dec 14 '11 at 00:39
  • 34
    The actual problem is classifying other programmers into cowboy or quick&dirty or other titles. Every programmer has some failure modes, and reading someone elses code is very difficult, and finding your own failures is very difficult. All these together means that people too easily label other programmers as bad ones, while thinking their own code is perfect – tp1 Dec 14 '11 at 01:08
  • 1
    I don't think my own code is perfect. I just take precautions to try to catch my imperfections. – asthasr Dec 14 '11 at 02:04
  • and others will interpret that as a sign of you being a bad coder... Or will simply dismiss your bracing or naming style as being a sign of you being a bad coder. I've seen both happen. – jwenting Dec 14 '11 at 07:20
  • 3
    @tp1: Good programmers can write code that is easy to read. They do this by having someone else read it, and clarifying anything that is unclear. With practice, the portion that is unclear on first reading will shrink. – kevin cline Dec 14 '11 at 08:06
  • 9
    @JimThio, do you seriously think that any of the programmers referred to above have ever intentionally written bad code? Have you ever read code written by yourself a few years back? Did you find it good? Chances are, you did your best back then, and you still see an awful lot of things to be improved in that code now. – Péter Török Dec 14 '11 at 11:34
  • Well, I do write jerk codes. Then When I open a project, the project will require another file. I add that file and that file require another file, then I add that file and that file requires another file. Then, I ended up with so many files the program doesn't need. I ended up having to correct really really old codes that are no longer used on files I do not need. Why? Because I don't bother structure dependency. Well, subject for another question. – user4951 Dec 14 '11 at 11:37
  • 1
    Immeasureable amounts of perfect code has gone to waste because it wasn't just quite perfect enough when the window of opportunity was open. – otto Dec 14 '11 at 13:55
  • 2
    I'd consider myself somewhat of a "Cowboy Coder", but I go out of my way to write readable, maintainable code. I don't think you can lump all "Cowboys" into one bucket. – jessecurry Dec 14 '11 at 17:04
  • Often "simply don't understand all of the potential failure modes" can be replaced with "don't care". The point of caring (for me atleast) is that it saves you stress, headaches and overtime later on – Chris S Dec 14 '11 at 19:46
  • My personal experience is that I have a buffer before I actually commit code/work that will have serious consequences. Back at school the way I deal with homework assignment is that sometimes I solved it in a quick and dirty way early. The solution sinks into my long term memory. After a while, ideas about some errors or corner cases occur to me as the solution and question have moved into more permanent place in the brain. It's like an Eureka moment in some way. Then near the due date, I write down the final version and submit commit the final work. It has been working pretty well for me. – InformedA Nov 20 '14 at 23:14
106

Okay, at risk of being complete downvote-bait, I'm going to "devils advocate" the opposing view.

I propose that we developers have a tendency to get overly concerned about things like proper practice and code cleanliness. I suggest that, while those things are important, none of it matters if you never ship.

Anyone who's been in this business a while would probably agree that it would be possible to fiddle with a piece of software more or less indefinitely. Duke Nukem Forever, my friends. There comes a time when that nice-to-have feature or that oh so urgent refactoring work just should be set aside and the thing should be called DONE.

I've fought my colleagues about this many times. There's ALWAYS one more tweak, something else that "should" be done for it to be "right". You can ALWAYS find that. At some point, in the real world, good enough just has to be good enough. No real-world, actual, shipping software is perfect. None. At best, it's good enough.

Dan Ray
  • 9,106
  • 3
  • 37
  • 49
  • 2
    I think this is a reasonable position, one definitely has to be pragmatic. As someone who's done a LOT of code maintenance, I'm convinced that only crappy code lasts for decades, the clean stuff is abandoned when the next shiny thing comes along. – Steve Jackson Dec 13 '11 at 18:04
  • 10
    Or maybe if it's used, hard, for decades, it will likely end up looking like a mess. If it isn't used (at all, or for long), it won't have a chance to accumulate any cruft. – Useless Dec 13 '11 at 18:32
  • Considering [this post](http://www.codinghorror.com/blog/2009/12/version-1-sucks-but-ship-it-anyway.html), I do wonder if SE itself has, at times, taken shortcuts to get things done... – Trav Dec 13 '11 at 19:33
  • 7
    "Anyone who's been in this business a while would probably agree that it would be possible to fiddle with a piece of software more or less indefinitely." It would be possible, but why do it? Once you have set your quality standard, you design it, implement it, test it, fix bugs, test it again, and then do not touch it any more. It takes longer than just hacking it but once you have reached your goal (required functionality is implemented and tested) it is quite clear that you should not fiddle with the code any more. Just my 2 cents. – Giorgio Dec 13 '11 at 19:54
  • 2
    *"none of it matters if you never ship"*... and yet that NEVER should be used as an excuse to avoid best practice as per your company's quality standards. I agree however that indefinite tweaking is a problem, but I'd argue that having a high degree of confidence in your code is not. – S.Robins Dec 13 '11 at 22:54
  • 7
    +1 -- in the real world there will always be a tradeoff between code quality and meeting deadlines. I would rather have a programer who can produce reasonable code quickly than a perfectionist who spends months agonizing over whether he should call a method "serialize" or "writeToFile". – James Anderson Dec 14 '11 at 01:56
  • 2
    +1, *we're not in the software writing business, we're in the software shipping business*. – GrandmasterB Dec 14 '11 at 05:10
  • 1
    +1 - well spoken. The high minded among us like to think of software as an art - but if you make your living doing it, it's mostly a craft and a business - the business of crafting usable software. – Vector Dec 14 '11 at 06:01
  • 3
    you said it. I've worked in an organisation where in the next room over was a team that'd been working on the functional requirements for a new system for the last 5 years, not a line of code has ever been written for it. Many coders are the same (especially juniors, fresh out of college with high ideas about code having to be beautiful and meet specific "standards" else it's bad) and will, unless stopped, fiddle endlessly with something that was perfectly functional months ago (I sometimes still have that tendency, I think we all do). But in the end, what matters is getting it out the door. – jwenting Dec 14 '11 at 07:24
  • 2
    Constantly fixing incomplete, undocumented, bugged, badly designed code, I tend to go more and more on the side "if you can't do it right, don't do it". If you don't have the resources to do it right and do it anyway, make sure you'll have orders of magnitude more resources than required later, when you have to fix everything before new, dependent, developments. – Joanis Dec 14 '11 at 07:37
  • 6
    @Giorgio: I disagree with your "superstition" that quality work takes longer than just hacking it. That might be true if you equate programming with typing. Considering the whole software lifecycle things go much smoother and therefore quicker if you care about quality. – ThomasX Dec 14 '11 at 07:49
  • @ThomasX: Maybe I should have made this clear in my comment: I agree with you! IMO if you hack you can (maybe) show something very quickly, but you probably have to spend much more time fixing or even rewriting it later, so the total time is probably more than doing it properly from the beginning. This is why I said that you should set a standard from the beginning (functional, design, test specification) and follow it until the requirements are implemented and tested. IMO it is when the requirements and quality standards are not clear that one might keep fiddling with the code forever. – Giorgio Dec 14 '11 at 08:04
  • @Giorgio - +1 for that too. You need to be a pro - that means you know very quickly how to approach something the right way, and how to write decent code instictively. A good developer never writes junky code - could have a bug, yes; could be lacking features or not particularly elegant, yes; But it can't be disorganized spaghetti - poorly organized and constructed. – Vector Dec 14 '11 at 08:11
  • 1
    There is a difference between feature creep (or quality creep in this case) and lack of quality from the first beginning of the development cycle on. I agree that software has to be shipped at some point and it will never be perfect, but that should not be an excuse for cowboy coding the entire time. At least not if maintainability matters for that project. – Adrian Grigore Dec 15 '11 at 11:42
  • Amen to that, and I gave it the 100th up vote. Also, consider that while avoiding closure to infinitely develop the pristine, text book specimen, the obsoletion clock continues to click and your development preferred stack and frameworks and methodologies are closer to being thrown in the "legacy" bin. – Thomas Carlisle Sep 06 '17 at 21:00
105

The code probably isn't right.

However, it may not matter.

Quick and dirty may be the right way to go in situations where:

  • The code has a short lifetime. For example, you're transforming a bunch of data into a standard format with an ad-hoc program.
  • The negative impact of failure is low:
    • The data you're transforming is non-critical, and errors in it can be easily corrected
    • The end-user is a sympathetic programmer, who will reason about error messages and work around them by, say, massaging the input.

Sometimes it's not important that code is robust and handles every conceivable input. Sometimes it just needs to handle the known data you have on hand.

In that situation, if unit tests help you get the code written faster (this is the case for me), then use them. Otherwise, code quick and dirty, get the job done. Bugs that don't trigger don't matter. Bugs you fix or work around on-the-fly don't matter.

What's absolutely vital is that you don't misdiagnose these situations. If you code quick-and-dirty because the code is only going to be used once, then someone decides to reuse the code in some project that deserves better code, that code deserved more care.

user24449
  • 232
  • 1
  • 6
slim
  • 799
  • 1
  • 6
  • 11
  • 26
    +1 for "the impact of failure is low." My favorite mathematical risk calculation is **risk = actual consequence of failure x probability of failure x perceived consequence of failure** (In my experience, the perceived risk the stakeholders often get stuck on) – Trav Dec 13 '11 at 19:46
  • 8
    "The code has a short lifetime. For example, you're transforming a bunch of data into a standard format with an ad-hoc program." What if the transformation isn't done correctly, but discrepancies in the data aren't noticed until much later on? – Joey Adams Dec 15 '11 at 03:42
  • 3
    @Trav So, just to confirm, if the actual consequence of failure is massive, but my perceived consequence of failure is zero, there is no risk whatsoever? – Christian Stewart Apr 22 '14 at 19:27
  • 3
    @ChristianStewart From a purely mathematical standpoint, your assertion would be correct. However, in practice, a perception of consequence being zero would not negate the weight of the probability x actual consequence. The perception is placed into the formula to account for organizational fears that often influence mitigation decisions. The lack of such fear does not lessen the actual probability or consequences. Thus, one should assume that perception is always at least equal to 1 (since it can magnify but not negate in any way actual risk) – Trav May 07 '14 at 18:41
  • 2
    @Trav Alternatively, rename one. Namely, **risk** ought to be swapped to **perceived risk**, since if we believe that there's no consequences of failure we likely also believe there's no risk. – Delioth Sep 06 '17 at 21:35
83

Such programmers almost never know they got it right, only believe so. And the difference may not be easy to perceive.

I remember how I used to program before I learned about unit testing. And I remember that feeling of confidence and trust on a wholly different level after I ran my first decent suite of unit tests. I hadn't known such level of confidence in my code existed before.

For someone who lacks this experience, it is impossible to explain the difference. So they may even go on developing in code-and-pray mode throughout their life, benevolently (and ignorantly) believing that they are doing their best considering the circumstances.

That said, there can indeed be great programmers and exceptional cases, when one really manages to hold the whole problem space in his/her mind, in a complete state of flow. I have experienced rare moments like this, when I perfectly knew what to write, the code just flew out of me effortlessly, I could foresee all special cases and boundary conditions, and the resulting code just worked. I have no doubt there are programming geniuses out there who can stay in such state of flow for extended periods or even most of their time, and what they produce is beautiful code, seemingly without effort. I guess such persons might feel no need to write puny unit tests to verify what they already know. And if you really are such a genius, it may be OK (although even then, you won't be around that project forever, and you should think about your successors...). But if not...

And let's face it, chances are you aren't. I, for myself, know I am not. I had some rare moments of flow - and countless hours of grief and sorrow, usually caused by my own mistakes. It's better be honest and realistic. In fact, I believe the greatest programmers are fully aware of their own fallibility and past mistakes, so they have consciously developed the habit of double checking their assumptions and writing those little unit tests, to keep themselves on the safe side. ("I am not a great programmer - just a good programmer with great habits." - Kent Beck.)

Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • `"write puny unit tests to verify what they already know"`, http://www.imdb.com/title/tt0139654/quotes?qt=qt0250813 – StuperUser Dec 13 '11 at 16:54
  • 8
    "benevolently (and ignorantly) believing that they are doing their best considering the circumstances." Perfect summary of the problem. #1 rushed because of constraints and did the best he could. #2 comes along and has inherited chaos plus new deadlines and does his best too. All the way down to the 20th poor soul who couldn't do his best if he had years to undo the damage. That's why I practice the Boy Scout rule, "leave it cleaner than you found it." Give that next sap a fighting chance - it might be you. – Steve Jackson Dec 13 '11 at 17:41
  • 1
    Funny, I feel the opposite since I've started unit testing my code (at work). It's like getting lazy; there's no reason to _really understand_ your code, since other code will catch mistakes for you – Izkata Dec 13 '11 at 18:08
  • 8
    You write unit tests in *part* to prove that your own code works. More importantly, you write unit tests so that *other* developers can alter your code with confidence. – Stephen Gross Dec 13 '11 at 19:11
  • 4
    Donald Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it." http://haacked.com/archive/2007/11/29/awesome-knuth-quote-on-code-proofs.aspx – MarkJ Dec 13 '11 at 20:30
  • +1 for the Kent Beck quote. Strive to be the humble programmer who knows that good practice makes the difference, even if it feels there is still has much to learn. That in itself signals to others quite eloquently that you're in the league of "greater" programmers. – S.Robins Dec 13 '11 at 22:52
  • 1
    @Izkata - if you don't understand what you're doing, the unit tests are probably broken, and validating that the code has the same mistakes that the tests do. Also, even with 100% decision coverage and accurate unit tests, it's possible (though unusual) to have a bug that testing doesn't reveal. –  Dec 14 '11 at 05:22
  • @MarkJ - that quote is out of context. When you know the context, it's a good quote for arguing that mathematical proofs are insufficient, and that some form of testing of the code is necessary - with unit testing being one of the possibilities. –  Dec 14 '11 at 05:28
  • @Steve Yes it is, that is why I quoted it. It does say "beware of bugs" – MarkJ Dec 14 '11 at 05:30
  • @MarkJ - Sorry - I was convinced you were suggesting something else. I don't know why now. Probably I shouldn't comment at silly-O'clock in the morning. –  Dec 14 '11 at 09:25
  • This is definitely the most insightful answer here. Thanks for sharing. – Engineer Dec 14 '11 at 11:24
35

Unit tests. Its the only way to have confidence in any code (dirty or not).

On a side note;

short cuts make for long delays (Pippin)

Tom Squires
  • 17,695
  • 11
  • 67
  • 88
  • 1
    No shortcut, no Gandalf 2.0. – jfrankcarr Dec 13 '11 at 16:30
  • 6
    Good quote, but it wasn't Gandalf. It was Pippin, arguing why he, Frodo and Sam shouldn't cut across country to the Buckleberry Ferry, right in the initial journey from Hobbiton. – Daniel Roseman Dec 13 '11 at 16:48
  • I stand corrected! – Tom Squires Dec 13 '11 at 16:53
  • I was going to write this - if you have unit tests, Q&D code can be alright, as long as it doesn't overwhelm the codebase, and the tests are sufficient. – Marcin Dec 13 '11 at 18:25
  • 22
    Correction: "Unit tests. Its the only way to have false sense of security in code (dirty or not)". Unit tests are good to have, but they don't guarantee anything. – Coder Dec 13 '11 at 19:12
  • -1 for for misquoting Gandalf; +1 for quoting Pippin. – Stephen Gross Dec 13 '11 at 19:12
  • 9
    When I want to uncover hidden bugs, I show the app to my boss. I call it the boss-test, it is to be made after unit testing. He has an aura of magnetism that atracts all kind of weird bugs as well as cosmic rays straight to CPU registers. – Mister Smith Dec 13 '11 at 22:46
  • 8
    While we're quoting, you might also like "Testing shows the presence, not the absence of bugs" - Edsger Dijkstra – Timothy Jones Dec 14 '11 at 06:28
  • 2
    unit tests give a false sense of security. They're one way to verify your code, but no indication of whether it's doing what it should (as I keep asking people: who tests the test?). I've seen almost as much code fail or pass unit tests because of flaws in the tests as I've seen tests correctly indicate problems in code. – jwenting Dec 14 '11 at 07:26
  • "Short cuts make things shorter" (Mikey) – Vector Dec 14 '11 at 08:12
  • @Mister Smith - if possible, show it to one of your users - they're even better than your boss.... – Vector Dec 14 '11 at 16:58
  • 3
    -1 tests will not prove messy code right--unit tests don't PROVE anything, they give you a measure of confidence but are not worth anything more than that. They are a good measure, just don't go assuming they mean more than that a small sub-section of code works exactly as you wrote it, it doesn't say you wrote it correctly or that it will interact correctly with anything else.. Although they are generally a good measure but they are no help with crappy code and will actually make it worse by giving you more code to change with each refactor. – Bill K Dec 14 '11 at 17:18
  • 2
    A counter-argument to unit tests: how did people know their code was "correct" before the days of unit test frameworks? The source code for BSD, for example – Chris S Dec 14 '11 at 19:49
15

It’s good to learn to accept that no software system of reasonable complexity will be perfect no matter how much unit testing and code tweaking is done. Some degree of chaos and vulnerability to the unexpected will always lurk within the code. This doesn’t mean that one shouldn’t try to produce good code or conduct unit tests. These are, of course, important. There’s a balance that has to be sought and this will vary from project to project.

The skill to be developed is an understanding of what level of ‘perfection’ needs to be used for a particular project. For example, if you’re writing an electronic medical records application with a 12 month project timeline you’ll want to devote a lot more time for testing and making sure your code is maintainable than you would for a one-off conference registration web app that has to be deployed by Friday. Problems arrive when somebody doing the EMR app gets sloppy or the registration app doesn’t get deployed in time because the programmer is too busy tweaking code.

jfrankcarr
  • 5,082
  • 2
  • 19
  • 25
  • 1
    +1 for pointing out that decisions about quality measures have to be justified by business needs. – Stephen Gross Dec 13 '11 at 19:14
  • +1 for *"The skill to be developed is an understanding of what level of ‘perfection’ needs to be used for a particular project."... Set a minimum standard for how much "tweaking" your company feels will be an acceptable risk in terms of quality, then stick to it. – S.Robins Dec 13 '11 at 22:58
11

Quick and dirty is perfectly fine within a subsystem. If you have a well defined interface between your crap and the rest of the system, and a good set of unit tests that verify that you ugly quick and dirty code does the right thing, it may be perfectly fine.

For example, maybe you have some hideous hack of regular expressions and byte offsets to parse some files coming from a third party. And assume you have a test saying that the result you get out of parsing example files is what you expect. You could clean this up so that you could ... I don't know, react more quickly when a third party changes a file format? That just doesn't happen often enough. More likely they'll change to a completely new API and you'll throw away the old parser and plug in a new one that conforms to the same API, and voila, you're done.

Where quick and dirty becomes a problem is when your architecture is quick and dirty. Your core domain object need to be well thought out, and your interfaces, but the edges of your system can usually be messy without ever having to pay the piper.

Kevin Peterson
  • 429
  • 2
  • 5
9

Here's a story about a quick and dirty programmer I know.

I've known a person who regards unit tests a waste of time. After much argument, he finally wrote one. It consisted of one long method sprinkled with && and || and returned a boolean to assertTrue. The statement span 20 lines. Then again, he wrote a class where every method had one line and a main one had over 1000 lines with no whitespaces. It was a wall of text. When I reviewed his code and inserted some new lines, he asked 'why'. I said 'Because of readability'. He sighed and deleted them. He put a comment on top "Don't touch it, it works!"

Last time I talked to him, he coded a website for a company. He was trying to find a bug. He had spent the last 3 days doing that for 8 hours a day. A bit later I talked to him again, and it turned out his team mate changed the value of a literal and didn't update it else where. It wasn't a constant. So he changed the other literals too so that his bug got fixed. He complained about his team mate's spaghetti code. He told me 'Haha, don't we all know what it's like to stay up whole night with the debugger, not getting any sleep over one nasty bug" He think this is something really good programmers do and he actually feels good about it.

Also, he thinks reading programming books and blogs is useless. He says, 'just start programming'. He's done that for 12 years and he thinks he's an excellent programmer. /facepalm

Here's some more.

Another time we were writing a DatabaseManager class for our web app. He put all database calls in it. It was a God class with over 50 methods for every imaginable thing. I suggested we break it up into subclasses because not every controller needs to know about every database method. He disagreed, because it was 'easy' to just have one class for the whole database and it was 'fast' to add a new method whenever we needed one. In the end, DatabaseManager had over 100 public methods from authenticating the user to sorting archaeological site locations.

siamii
  • 1,330
  • 11
  • 23
7

My lesson in avoiding quick and dirty was when I had six months to deliver what was estimated (under-estimated) to be a year's worth of work. I decided to research methodologies before starting work. In the end I invested three months of research and was able to deliver in the remaining three months.

We got big gains by identifying common functionality and building the required libraries to handle those requirements. I still see coders writing their own code when there are available library routines. These coders often rewrite, or at best cut and paste, the same code when they need to solve the same problem later. Bug fixes invariably only catch some of the code copies.

One developer gave a telling reply when I asked him to use library code: "Isn't that cheating? I had to write all my own code in school."

BillThor
  • 6,232
  • 17
  • 17
7

The product ships.

Code doesn't exist in a vacuum. I have suffered untold grief firefighting the consequences of quick and dirty and cowboy coding. But sometimes finishing the product is the priority, not figuring out how to write the best code. Ultimately, if the product ships and works well enough, the users and customers won't know or care how "bad" the code inside is, and I will admit there have been times when I didn't care at all about "getting it right" as long as I got it out the door.

Yes, this in an organizational issue and "should never happen." But if you happen to be writing code in an organization that is poorly managed and heavily deadline-driven, at the individual programmer level one's options are limited.

Suboptimus
  • 111
  • 2
6

In some cases I guess there could be a large suite of regressiontests that will find "all" bugs and verify the behaviour, thereby allowing for a quick and dirty coding technique. But mostly its just a matter of bad project planning and a manager who thinks its more important to get it done, than to get it done right.

And forget about "clean it up later", that never happens. In the rare cases it happens, the programmer will have forgotten most of the code making the job alot more expensive than if he had done it right the first time.

Fredrik
  • 803
  • 6
  • 12
5

I don't think they can honestly say they got it right if it's not easily maintainable. If they admit they have to "clean it up later", then there is likely something they haven't thought through enough. Testing it thoroughly will only truly uncover any issues with dirty code.

I personally wouldn't aim to develop the skill of "writing dirty code" and being confident about its correctness. I would rather write proper code the first time around.

Bernard
  • 8,859
  • 31
  • 40
5

How do they know they got it right? Testing is the simple answer.

If their code has been tested thoroughly by a good QA team and it passes, then I would say they got it right.

Writing quick and dirty code is not something that should be done as a habit but at the same time there are occasions when you can spend 20 mins writing code that may be classed as dirty or 4 hours refactoring a lot of code to do it right. In the business world sometimes 20mins is all that is available to do the job and when you face deadlines quick and dirty may be the only option.

I have myself been on both ends of this, I have had to fix the dirty code and have had to write my own in order to work around the limitations of a system I was developing in. I would say I had confidence in the code I wrote because although it was dirty and a bit of a hack sometimes I did make sure it was thoroughly tested and had a lot of built in error handling so if something did go wrong it wouldnt destroy the rest of the system.

When we look down on these quick and dirty programmers we do need to remember one thing, a customer generally doesnt pay till they have the product, if it ships and they go into UAT testing and find the bugs from quick and dirty code it is a lot less likely they will pull out when they have an almost working product infront of them, yet if they have nothing and you are telling them "you will have it soon we are just fixing x" or "it was delayed because we had to get y working just perfectly" they are more likely to give up and go with a competitor.

Of course as this image demonstrates no one should underestimate the danger of quick and dirty code! enter image description here

Purplegoldfish
  • 121
  • 2
4

I don't think you should even start going down that road. Quick and dirty might give you the temporal benefit of finishing faster, but you always pay ten-foldedly for doing this in the end.

Raku
  • 1,083
  • 6
  • 12
  • 5
    Sometimes you won't have any money if you don't ship now...but shipping now, allows you to pay "ten-fold" to clean it up, and then some because you beat your competitors to the market, and got brand recognition first. – CaffGeek Dec 13 '11 at 15:53
  • 2
    I beg to differ. If money is tight already, you spend the income on the next product and you'll keep doing so until your company either dies or gets big enough. In the latter case and most likely, the original developers won't be there anymore to fix the old code. – Raku Dec 13 '11 at 15:57
  • Beating others to market is no guarantee that the public will accept your product. If a product contains too many flaws, you'd better hope you've got the extra cash to apply some good smoke and mirror marketing, and have a brilliant and forgiving relationship with your customer base. This isn't an either/or position. The key is to balance risk vs reward, and release the highest quality product you can provide in a timely manner. Your skills will be judged by the quality of product you release, and the damage that flawed software can do to your image can be irreparable. – S.Robins Dec 13 '11 at 23:04
  • 1
    Beg to differ all you like, but history is full of examples where being there at the right time, available to whoever wanted it, was more important than being the best possible product. There's always an opportunity cost, always always. – Warren P Dec 20 '11 at 20:06
  • 1
    Warren, that's basically what I was saying. In my eyes the opportunity cost of getting the code back to maintainable grows, exponentially, the longer you delay it. If your company is in a position where it can survive the unmaintainability disaster because sales went well and the code wasn't too dirty, good, but what if not? – Raku Dec 21 '11 at 09:27
4

In my opinion, learning to judge Q&D code for correctness is not a skill worth developing because it's just bad practice. Here's why:

I don't think "quick and dirty" and "best-practice" go together at all. Many coders (myself included) have cranked out quick and dirty code as a result of a skew in the triple constraints. When I've had to do it, it was usually a result of scope creep combined with a ever-approaching deadline. I knew the code I was checking in sucked, but it spit out proper outputs given a set of inputs. Very importantly to our stakeholders, we shipped on time.

A look at the original CHAOS Report makes it pretty clear that Q&D is not a good idea and will kill the budget later (either in maintenance or during expansion). Learning how to judge if Q&D code is right is a waste of time. As Peter Drucker said, "There is nothing so useless as doing efficiently that which should not be done at all."

Trav
  • 226
  • 1
  • 6
3

I can't tell if my new code is correct if it's too dirty.

"Dirty" means different things to different people. To me, it mostly means relying on things that you know you probably shouldn't rely on, but which you also know that you can expect to work in the near term. Examples: assuming that a button is 20 pixels high instead of calculating the height; hard coding an IP address instead of resolving a name; counting on an array to be sorted because you know that it is, even though the method that provides the array doesn't guarantee it.

Dirty code is fragile -- you can test it and know that it works now, but it's a pretty good bet that it'll break at some point in the future (or else force everyone to walk on eggshells for fear of breaking it).

Caleb
  • 38,959
  • 8
  • 94
  • 152
3

At the risk of sounding a little controversial, I'd argue that nobody truly KNOWS that their code is 100% correct and 100% without error. Even when you have really good test coverage and you are rigorously applying good BDD/TDD practices, you can still develop code that contains errors, and yes that can even contain side-effects!

Just writing code and assuming it works implies overconfidence on the part of the developer's sense of that developer's own abilities, and that when problems arise (which they inevitably will) the effort to debug and maintain the code will be costly, especially if another developer needs to maintain the code later on. The real difference is made by applying good software engineering practices, which ensure that you can have real confidence that your code is likely to work most of the time, and that if you do encounter an error, it is more likely to be easier to debug and much less costly to change and maintain regardless of the person who works on that code later on.

The salient point is that well factored and well tested code will allow OTHERS to have confidence in your code, which is in most cases more important than your own confidence.

S.Robins
  • 11,385
  • 2
  • 36
  • 52
2

If dirty code is well tested, it can be trusted. The problem is, that unit testing dirty code is usually very hard and cumbersome. This is why TDD is so good; it reveals and removes dirt and smells. Also, unit testing is often the first thing to suffer from time preasure. So if the cleanest guy ever made the cleanest code he'd ever done, I would still not trust it one bit, if he omitted the unit tests due to time preassure.

Morten
  • 903
  • 7
  • 17
2

Good programmers (Quick & Dirty and otherwise) do not have the hubris to assume they have got it right. They assume that all large systems have bugs and flaws, but that at some point might be well enough tested and reviewed to have a sufficiently low risk or low enough cost of failure that the code can ship.

So why do these, so called Quick & Dirty, programmers, exist? My hypothesis is Darwinian selection. Programmers who ship workable code fast, occasionally ship before the competition ships, or the budget runs out, or the company goes bankrupt. Therefore their companies are still in business employing new programmers to complain about the mess that has to be cleaned up. So called clean code ships as well, but not differentially well enough to drive Quick & Dirty coders into extinction.

hotpaw2
  • 7,938
  • 4
  • 21
  • 47
  • This is true. I have seen at least one product that was able to ship due to Quick & Dirty code, warts and all. It so happened that a couple days vs. a month up front meant a two month jump on the competition. The product went on to be a success and the Quick & Dirty code was eventually replaced with better code. Ever since seeing that I try to do a better job of viewing my code quality from not only an engineering standpoint but also from a business/competitive view. Note: the interface of said code was fine, it was the implementation that was sketchy. – J Trana Jan 08 '15 at 06:04
0

One may probably think that a not optimal part of a code could make no difference, because of the short lifetime, little impact in business, or little time to get it done. The correct answer is you don't really know. Every time I listen to somebody saying that "this is a small feature", or "let's make it as fast and as simple as we can" and spend insufficient time on thinking about the right design, the only two things that actually and up occurring are:

1-) The project get's bigger and the team motivation lower, working on code full of "stitches". In that case the project will probable to a fast lane towards chaos.

2-) The project becomes known to be a non optimal solution and its use starts to be discouraged, in favor of a new solution or a refactoring that is as expensive as a new solution.

Try always to do the best code you can. If you don't have enough time, explain why you need more. Don't put yourself at risk with poorly made work. Be always a better professional. No one can punish you for this if you are reasonable. If they do, it's not where you should care to work at.

Thiago Gama
  • 1
  • 1
0

Discuss with the senior and assess the impact of failures if any. For example a situation where you can fix dirty takes 1 day and a robust code requires design and architectural change which may take 4-6 months + additional validation time to completely validate all the workflows which got impacted with the design change.

We have to take a decision based on Time + Capacity + Priorities in the list as well. A good discussion in the team with seniors or people with higher experience can help land on a decision which best fits the team and its deliverable.

Clean code is the first and foremost approach where as dirty code to save the escalations, go/no go decisions of the clients, show stoppers, reputation of the organisation at the stake and many more where dirty code makes it way into clean code.

Mendy
  • 1
  • 1
  • 4
    this doesn't seem to offer anything substantial over points made and explained in prior 23 answers – gnat Sep 06 '17 at 17:35