Forgot your password?
typodupeerror
Programming The Almighty Buck IT Technology

"Quick 'n Dirty" vs. "Correct and Proper"? 887

Posted by Cliff
from the which-way-would-you-go dept.
A not-so Anonymous Coward enters this query: "I keep finding myself on projects where a quick and dirty solution will bring in money for the company, and a correct (ie, properly documented, well engineered, process followed, etc) solution will get us left in the dust. When the Q&D solution succeeds, I'm left trying to explain why it can't be the FINAL solution (to PHBs and Marketroids that were fully informed of the situation prior to any work getting done). Most recently, work I did in record time was used to help bring in several large contracts, and then I found myself in hot water for not having followed process et al. So, to Slashdot: is it better to do the quick thing and greatly increase the chance of $uccess now, or to do the correct thing and avoid pain later (assuming there is money to pay for the pain later)?"
This discussion has been archived. No new comments can be posted.

"Quick 'n Dirty" vs. "Correct and Proper"?

Comments Filter:
  • No easy answer (Score:5, Insightful)

    by bartlog (154332) on Thursday July 10, 2003 @05:58PM (#6410137)
    There's no definite answer to your question. You must judge the circumstances and make the call. Much as we'd like to do everything properly, quick and dirty is often first-to-market - and I've used plenty of products that had significant bugs and yet were adequate for my purpose.
  • Correct and Proper (Score:4, Insightful)

    by dylan95 (307651) on Thursday July 10, 2003 @05:59PM (#6410147) Homepage
    Correct and Proper
    Otherwise you're going to spend all your quick cash on fixing bugs and supporting craptacular software, not to mention bad press and angry users.
  • by Anonymous Coward on Thursday July 10, 2003 @05:59PM (#6410148)
    You don't state your position. Your manager should be getting proper sign-off for you. If that's your role, you're not doing a good job of it. Let the right people know, via email, and get confirmation, via email. Always do whatever is right for the situation. Sometimes it's quick and dirty, others it's slow and proper. Note that even quick and dirty can be well documented and follow process.
  • by mrybczyn (515205) on Thursday July 10, 2003 @05:59PM (#6410153)
    Companies aiming for $uccess while compromising the quality of their software will only obtain this success in the very short term... Do what they want now, but look for better pastures while you're doing it, because your company won't be around for long.
  • by Anonymous Coward on Thursday July 10, 2003 @06:00PM (#6410171)
    Just let the marketing guys do the math:
    Quick and dirty solution:
    $1000 to make
    $100000 to support
    or
    Proper solution:
    $10000 to make
    $10000 to support
  • Personally (Score:5, Insightful)

    by elBart0 (444317) <slashdot AT bibax DOT com> on Thursday July 10, 2003 @06:00PM (#6410172) Homepage
    I'd rather work for a company that's in business two years down the road, than work for a company that got lost in the dust.

    But, ultimately I think the answer to the question lies in the actual type of work being done. Throwing together a quick app convert some data from one format to another, for one time use, is very different from building mission critical applications.

    The end result and the time required to meet that result will ultimately determine the correct approach, on a case by case basis.
  • by SweetAndSourJesus (555410) <JesusAndTheRobot&yahoo,com> on Thursday July 10, 2003 @06:01PM (#6410178)
    Unless your contracts allow "as long as it takes" as a deadline.

    Sometimes quick and as proper as possible (but mostly quick) is your only option.
  • by Capital_Z (682911) on Thursday July 10, 2003 @06:01PM (#6410186)
    What you describe is not a social problem - it is a human nature problem.
  • Do it right. (Score:5, Insightful)

    by nuggz (69912) on Thursday July 10, 2003 @06:01PM (#6410187) Homepage
    If quick and dirty works good enough, then it should be the final solutions.

    If it does not work good enough, then no matter how quick it is, it isn't a solution.

    The procedure is there for a reason, follow it. If the procedure is wrong correct it.
  • by whistler36 (189652) * on Thursday July 10, 2003 @06:01PM (#6410189)
    I always assume that code that can be easily maintained (which is the assumed outcome of following the process) will be cheaper and more appreciated in the end. It might be better to examine what is happening at the company when you are consistently left without enough time do it the correct way. Of course, if management is composed of morons (Could this actually happen?) you might not be left with any choice.
  • by shaka999 (335100) on Thursday July 10, 2003 @06:02PM (#6410198)
    I have to [somewhat] disagree here.

    Usually the product that wasn't released within a market window fails. If your product is late out the door you don't stand a chance.
  • Quick & Dirty (Score:2, Insightful)

    by Anonymous Coward on Thursday July 10, 2003 @06:02PM (#6410199)
    George S. Patton Once Said...
    "A good plan, violently executed now, is better than a perfect plan next week"
    If its good enough for the US Third Army it must be good for Corporate America...
  • by Crashmarik (635988) on Thursday July 10, 2003 @06:03PM (#6410205)
    Custom Development should never be sold without maintenance.

    Document what your nominal superiors specifically asked you to do and when the maintenance costs go out of control present the doc. All things being equal the contract will cover much of the cost of correcting things and some will learn the benefits of doing things right from the begining.
  • by paj1234 (234750) on Thursday July 10, 2003 @06:03PM (#6410211)
    Do it quick and dirty on the inside, make it look glossy on the outside. A short term fortune awaits...
  • by The Bungi (221687) <thebungi@gmail.com> on Thursday July 10, 2003 @06:03PM (#6410212) Homepage
    In my experience problems like these won't ever end until you prove yourself first by implementing The Right Way at least once. Before that the PHB just thinks you want to play|learn on company dime|extend your contract.

    Once you've done it correctly once, they're much more likely to be putty in your hands, because you've gained credibility.

    Of course the trick is to get that first success, and, sometimes, to convince them that the thing doesn't break because it was fscking done correctly, not because it's simple. Many times you end up making things look easy when they're really not, and that gives the wrong impression. Sigh.

    But anyway, having a half-intelligent PHB also helps =)

  • by SlashdotLemming (640272) on Thursday July 10, 2003 @06:03PM (#6410215)
    The Unified Process and Extreme Programming are more than buzz words.
    My point here is learn how to develop iteratively and incrementally, so that your first quick and dirty cut is on the path should the project continue.
    The key is to learn how to identify high risk items early, and learn what you can and cannot take shortcuts on.

    Harder that it sounds, as always :)
  • Depends. (Score:2, Insightful)

    by davidsheckler (45018) on Thursday July 10, 2003 @06:04PM (#6410226) Homepage
    When you do something quick and dirty, do you have
    to maintain it? Or will that task be left to
    some other poor slob who will bitch and moan
    about the piss poor coding you did.

    If you have to maintain it, do it right. You'll
    be the person getting phone calls in the middle
    of the night if you don't.

    Of course you should always produce clean, well
    tested code if you have any morals.

    I guess the real answer is do the best you can
    with what you're given. Make sure those in
    charge know what you're doing and why you're
    doing it. Are you, and your company satisfied
    with the end result? If not, go back to start
    and take a look at your methodology.

    It reality only the government and
    aerospace can afford true software engineering.
  • by SunPin (596554) <slashspam AT cyberista DOT com> on Thursday July 10, 2003 @06:04PM (#6410227) Homepage
    This is precisely why I work on referrals only. Random customers hear about how great you are and then expect perfection in five business days.

    Referrals create an environment where one customer understands what the last one went through and why they decided to allow the project time.

    Be up front. If you want a quick timeframe, you lose future expandability. If you want a robust program that won't be obsolete when a business process changes then that requires more time.

    That way, it's the customer's decision and not yours.
  • by Liselle (684663) <slashdotNO@SPAMliselle.net> on Thursday July 10, 2003 @06:04PM (#6410230) Journal
    Sometimes it's necessary to do something "quick and dirty" as a stopgap, but it's my opinion that it should only be used as an emergency strategy, to be followed up with a permanent solution ASAP.

    I work at a small software company that operates in a niche market, though we have competitors. I am not a developer, but I work closely with them (I do QA). I have lost count of how many times one of the devs has slapped on a band-aid fix, made a build, shot it up to the company FTP, and next thing I know, I am dealing with irate clients who have to deal with bug fallout and unforseen consequences.

    It it ALWAYS better to plan ahead, and do it right the first time. Money comes and goes, but your reputation is more important in the long run than any short term monetary gain.
  • by DNS-and-BIND (461968) on Thursday July 10, 2003 @06:05PM (#6410234) Homepage
    What if your bosses told you you had to fuck 10 women by 5pm Friday afternoon?
  • by IthnkImParanoid (410494) on Thursday July 10, 2003 @06:05PM (#6410239)
    I use so many programs on a daily basis that were just thrown together (by me or someone else). They are not extensible, they have a limited set of features, and they'd be a pain to maintain, but they do what I need them to do now, and no one else really uses them.

    It's much different when you're designing a program that will be used by many people for many years, and as such will need to be maintained and extended throughout it's lifetime, possibly after you've left. If you're on a tight deadline and you have to kludge something to get a contract or whatnot, make sure your boss fully understands that the program will not have a long lifespan, and let them make the call. (that will depend on how pointy your boss' hair is, of course.
  • by Anonymous Coward on Thursday July 10, 2003 @06:06PM (#6410250)
    if you know well enough what you're doing,
    Quick & Clean is possible .. unfortunately,
    if you're breaking new ground, that isn't
    always an option.

    the fact is - you get paid by producing what
    your company wants/needs .. do it how you have
    to do it and try your best to not get fed to
    the wolves when the shit hits the fan, which it
    invariably does. stick to a good, modular design.
    even if the innards of the components are dirty,
    design in such a way that you can replace these
    q&d parts with clean parts later - design is law!
    (hahahar) .. no matter how much of a rush you
    are in, it will save you time and effort to have
    a design document of some sort (even if its only
    in your head) .. don't just sit down and bang away
    unless you have a clear framework and path laid
    down somehow .. eventually you become skilled
    enough to Seem like you're just sitting down and
    banging away .. but you'll already have it written
    in your head

    clean and proper code is art, and art can't be
    rushed .. but a skilled artist can put out a good
    piece more quickly than a fledgling
  • by CausticWindow (632215) on Thursday July 10, 2003 @06:06PM (#6410254)

    You sure you actually improved it then?

    Clearing major changes with your cowworkers is generally a good thing.

  • by Atomizer (25193) on Thursday July 10, 2003 @06:07PM (#6410265)
    Yeah, totally right. Just look at that stupid company Microsoft that put out their first OS, QDOS? Quick and Dirty OS. Talk about a bad business move. Imagine how much richer Bill Gates could be today if he had only taken a few years to write a perfect from the ground up OS that would be easy to support and modify for the future. Something like BeOS maybe. That would be cool.
  • by jtdubs (61885) on Thursday July 10, 2003 @06:07PM (#6410267)
    So, would you rather put on a resume:

    1. I contributed to a project that got out the door quick and made lots of money for the company.

    2. I contributed to a project that was well engineered, and was so late to market that no one wanted it.

    I think most managers would rather see the first one...

    Justin Dubs
  • by sparkhead (589134) on Thursday July 10, 2003 @06:07PM (#6410274)
    [Obligatory MS bash]
    Tell that to Gates.
    [/obligatory MS bash]

    Seriously though, the "there's never time to do it right, but there's always time to do it over" camp has a lot going for it. If you cannot do it quick someone else will.

    On the surface a product riddled with bugs looks very similar to one thoroughly tested. Then when a customer starts filing defect reports, you can amaze them with your quick turnaround and great customer service in fixing them.

    It's a sad commentary, but it's how most business works.
  • by kelnos (564113) <bjt23NO@SPAMcornell.edu> on Thursday July 10, 2003 @06:08PM (#6410294) Homepage
    simple. if quick and dirty is getting you "in hot water" after the fact, and you have to spend countless hours explaining why the q&d solution can't be the final one, you're wasting precious time that you could be using working on your proper and correct solution. try to find middle ground - find the happy medium between q&d and p&c. it's there, and most often won't be the same deal for different projects.

    even if you're pressured to produce something - anything - that works in a short amount of time, at least have the foresight to put thought into it and plan for the need to do a partial redesign later. after your semi-q&d solution is released, begin working on turning it into as p&c as possible immediately. then when the phbs and marketroids come after you, you at least have something tangible to 'show' them.
  • by Chicane-UK (455253) <(moc.dlrowltn) (ta) (ku-enacihc)> on Thursday July 10, 2003 @06:11PM (#6410336) Homepage
    Where I work, it always seems to be the custom to 'just do enough to work around the current problem' - but the result is it always comes to bite us on the ass later on.

    In fact it has almost become legendary within the department that the powers that be will always choose the most blatantly inappropriate and half-assed solution to a problem, which leaves us picking up the pieces 6 or 12 months down the line.

    Do it properly - do it right the first time. It saves so much ballache later on down the line.. time you shave off a project now will just be time owed, and you can bet that it'll try and take the time back when its most inconvenient to you!
  • Re:Do Both. (Score:2, Insightful)

    by Jouster (144775) <slashdot@noSpAM.angelfaq.com> on Thursday July 10, 2003 @06:12PM (#6410340) Homepage Journal
    ...quick & dirty solution, then fix and document afterwards...


    Ever tried documenting Perl an hour after you wrote it? Especially if you were using lots of regular expressions?

    Do it right or do it not at all.

    Jouster
  • by BurKaZoiD (611246) on Thursday July 10, 2003 @06:14PM (#6410357)
    ...to keep your farking job. The whole point is to put money in your pocket and food on the table for your family anyway. I'm just as disgusted as any other programmer (who takes pride in their work) with QnD solutions, and I'm always left feeling it WASN'T my best work, but you know what? I always ask myself these three questions:
    1. Does it (the software) work?
    2. Does it (the software) do what it is supposed to do?
    3. Did I get paid?
    and if I can say "Yes" to all three of them, I find it much easier to live with QnD. Let the next generation sort out the spaghetti code. They've got to cut their teeth on something.
  • HTML or Assembly? (Score:5, Insightful)

    by stevejsmith (614145) on Thursday July 10, 2003 @06:21PM (#6410420) Homepage
    Am I the only one who thinks that this question is just an attempt to get onto the front page? It's such a vague question. It's so fucking relative. How "quick" and how "dirty" is it? Sometimes you need to skimp, sometimes you don't. Nobody here is qualified to give you a decision based on the facts that were given. "I need to do something: Should I do it quickly but shoddily or slowly but completely?" Well, if somebody is holding a gun up to your head and telling you to get something done, there's no point in commenting shit. If somebody is telling you to write something that must last until the next Ice Age, then do it properly. What the fuck kind of question is this? On another note, should I use HTML or Assembly? I just can't decide. Help me out, guys.
  • Both! (Score:5, Insightful)

    by Wonderkid (541329) on Thursday July 10, 2003 @06:22PM (#6410428) Homepage
    Excellent question, and one I face too this very day. The solution is to get a WELL DESIGNED product (whatever the product is does not matter) out the door as soon as possible, but keep the feature set simple to a) Keep it reliable b) Make your life easier c) Help potential customers grasp the concept. THEN, obtain funding and/or use income from Version 1.0 to maintain company stability while you work on the more sophisticated yet equally reliable Version 1.1 or 2.0. alex@owonder.com
  • Re:No easy answer (Score:4, Insightful)

    by geekmetal (682313) <vkeerthy.gmail@com> on Thursday July 10, 2003 @06:24PM (#6410455) Journal
    What we need to do is draw a line as to how dirty it can get (analytical skills here).

    Analyze where in the market you stand and ask some quick questions
    1) How much time do you have
    2) How much cash do you have

    Is this product aimed for a quick money making scheme or a long lasting product?

    and many more such questions to ponder about and you might just have your answer.

    As a programmer the worst part about the quick scheme is to have to take blame for a buggy code which was a direct result of the demand on time by your manager, regardless of the warnings you gave. But then wehn you see it from the eyes of the marketing person its a different story.
  • by tmoertel (38456) on Thursday July 10, 2003 @06:27PM (#6410489) Homepage Journal
    Quick-and-dirty vs. Do-the-right-thing -- what's the right choice? Let's consider the evidence:
    I keep finding myself on projects where a quick and dirty solution will bring in money for the company, and a correct (ie, properly documented, well engineered, process followed, etc) solution will get us left in the dust.
    If this is true, then the author of the original post has answered his own question: The quick-and-dirty solution was the correct solution. What he had initially labeled as "correct" -- good docs, adherence to sound processes, and so forth -- according to his analysis wasn't viable; it would have caused his company to be "left in the dust."

    So he did the right thing.

    And yet, he offers this testimony later:

    Most recently, work I did in record time was used to help bring in several large contracts, and then I found myself in hot water for not having followed process et al.
    What went wrong? I'll tell you what went wrong. The author apparently made the choice to go quick and dirty by himself. Instead, he should have forced his managers to make the call: If you want to go that fast, we'll have to cut corners. Are you willing to accept the consequences? Then he could have held them to their decision.

    If they came back to him later with complaints about quality or his deviation from internal processes, he would have had a sound rebuttal: You told me to cut corners, and that's what I did.

    But it's not always that simple. Sometimes it is irresponsible to cut corners, even when your managers direct you to do it. For example, if you're working in an engineering capacity, you have a responsibility to the public to protect their safety and well being. If your boss asks you to cut corners on the software that controls X-ray dosing in medical imaging equipment, your answer must be, No.

    Nevertheless, even in this case, the right thing to do is force the managers to make a decision, and hold them to it. I'm sorry, but I can't cut corners. We both have a responsibility to the public here, and so we have no choice but to find another way to meet our timelines. Agreed?

    So, to answer the final question:

    [I]s it better to do the quick thing and greatly increase the chance of $uccess now, or to do the correct thing and avoid pain later ... ?
    The answer is simple: It's not your call. Don't make it.
  • Re:Do it right. (Score:2, Insightful)

    by BlueFrog (104460) on Thursday July 10, 2003 @06:27PM (#6410491)
    I think you're missing something: time pressure.

    Solution:

    1. Deliver on time, even if you have to release an unmaintainable product.
    2. Profit.
    3. Make a second pass, re-write the thing, and end up ready for the next round of new features.
    4. When the time comes, go back to step 1.
  • by ChicagoDave (644806) on Thursday July 10, 2003 @06:29PM (#6410499) Homepage
    In order to move software to a well-architected foundation, you need something that works and costs too much to maintain, or, you need large pockets of start-up or reasearch and development cash.

    In the first case, you can relatively easily take headcount, hardware, and software expenses for segments of system development and show that over time, the complexity of any given system begins to turn nearly straight up. (Imagine a line graph with a line that goes from left to right for 2 years, then begins to incline slowly for 2 more years, then goes straight upwards from then on). So the justification for re-architecture is that you can move the complexity back down to a managable level, flatlining enhancement and maintenance costs for a few years, as opposed to continuing forever on the hugely expensive track you're currently on.

    The latter scenario is much more difficult to implement since no CEO I know likes to risk money on planned development unless there are buyers willing to wait. You may also find (unlikely) investors that feel so strongly about the foundation of the software that they're willing to risk the initial cash-flows.

    The best bet is to make every attempt to refactor things and build things with refactoring in mind as you make progress. Try to use a layered architecture....try to abstract as much as you can...leverage any and all talent on your team to accomplish things in a "ready to refactor" manner.

    There's no hard answer. It depends on where the cash is coming from, who the customers are, what state any current products are in, etc etc. It also depends what type of team you have. If you have a bunch of hackers, guess what...you're going to be writing quick and dirty code. If you have a team that understands structured development and you have strong development leadership, then you're far more likely to get buy-in for more formal development practices.

    It's always a battle and it sometimes comes from above, but there are many coders that would shoot you if you tried to get them to write anything down on paper first.

    Personally, I prefer a formal environment that _I'm_ in charge of. This way, I get to set the rules for when things can be hacked or not.
  • by Oloryn (3236) on Thursday July 10, 2003 @06:30PM (#6410504)
    I think most managers would rather see the first one...

    Problem is, they actually want to see both 'out quick' and 'well engineered', even if it's not possible.

  • Read history. (Score:2, Insightful)

    by Anonymous Coward on Thursday July 10, 2003 @06:30PM (#6410508)
    I think that you will find that there have been numerous variations on this theme over the ages. I also think that you will have a very difficult time finding EVEN ONE that would be described as successful by any reasonable person and has survived until today.

  • by Jboy_24 (88864) on Thursday July 10, 2003 @06:34PM (#6410535) Homepage
    And what do you want your new managers to hear on the reference call?

    Your old company probably would like to say,

    "um, yeah, Joe? Man, that guy coded up a storm and we got the project out, but we had to ditch all of his stuff when we wanted to go to Rev 2.0."

    "In the end, it cost use twice as much to develop 2.0 because we most of our time trying to upgrade his stuff, then we had to start over. Actually we nearly had a programmer quit when he heard he had to support the old Rev 1.0 customers. From now on, when our developers start to code quick and dirty, we tell them not to Joe the code."

    most likely your old company would say though,
    " yeah, Joe was young and inexpirenced. He was quick, but left unsupervised he tended to write code that wasn't usable elsewhere. As well, he kinda was tough to work with, he had a kinda prima-donna attitude. Would I hire him again? Umm... well... if i had some small one-off projects I needed done, I'd like him there, but I think in any large project work, he'd probably feel like the procedures were holding him back and he'd rebel"

  • by Xeger (20906) <slashdot@NoSPaM.tracker.xeger.net> on Thursday July 10, 2003 @06:34PM (#6410536) Homepage
    To decide whether to do something QnD ("quick and dirty") or PnP ("prim and proper"), you simply need to estimate the net gain of either approach.

    So, for QnD:
    gain = productLifetimeProfit + cashFromEarlyAdopters - (productLifetime * costOfMaintainingCrappyProduct)

    And for PnP:
    gain = productLifetimeProfit - cashFromEarlyAdopters

    So...Is cashFromEarlyAdopters >= (productLifetime * costOfMaintainingCrappyProduct) ? If so, then go ahead and do it the quick-and-dirty way for a greater net gain.

    Just make sure you have a reasonable estimate for your product lifetime, and also make sure you fully understand the costs of maintaining your crappy product.
  • Re:Example (Score:2, Insightful)

    by spideyct (250045) on Thursday July 10, 2003 @06:34PM (#6410538)
    How can you NOT be modded as a troll when you make a blanket statement and don't provide examples?
    Just because Microsoft software has bugs, doesn't mean they develop things "quick and dirty". Yes, I'm sure some stuff is pushed out the door before it's 100% clean, just like every other commercial software vendor. But that doesn't mean that they don't have stringent development processes.
    You could put any commercial software company's name in the first line of your post. But because you chose to use "Microsoft", I'll call it a troll.
  • Both! (Score:5, Insightful)

    by RandyF (588707) on Thursday July 10, 2003 @06:36PM (#6410556) Journal
    When you get a quick time-to-market deadline, make sure you spend at least a certain amount of time up front on the proper structure and upgrade methodology. The goal is to have a product to ship that is relatively painless to upgrade, or even, if you can swing it, built into the product life cycle (i.e.: software as a service). Then, lay out the guts and the gui, keeping in mind the features and tweaks that will come with the first upgrade.

    This is really the SOP (standard operating procedure) for most of the big dogs out there in softwareland. It works pretty good and is generally acceptable to the user community. Think pluggable, modular (sort of like OO for the youngsters in the house, but takes more thought and works better), and non-statically linked.

    On the OO comment, there are some good OO tools and languages out there, don't get me wrong. It's just that you have to understand good modular programming to keep from OOing yourself into spegetti code, which is way too common. OO != modular if it's not done right. OO != OO if you don't understand it. The same thing goes for RDMS work. If you don't understand relational theory and the underlying structure of the RDMS in question, you might as well be using text files and awk. (boy was that a rant or what? ;^)

    good luck and good programming!

  • by Lysol (11150) on Thursday July 10, 2003 @06:40PM (#6410585)
    Unfortunately, this is very hard. Business moves fast and programming, like any other science, can be very rigid and thusly unforgiving when 1 little thing is 'incorrect'.

    Most programmers I know like to take their time and think about stuff. Most biz people I know want the millions and want it yesterday - that's their job. There is very little middle road to walk here since money drives pretty much everything and ultimately that is the commanding force.

    Sure, you bnag something out, the contract get's signed and everyone's happy - for that moment. However, when bugs crop up, tensions flare and people start pointing fingers, etc..

    The only way I've seen it work - and I haven't seen it much - is to start from the get go and convince the people you work for/with that the project is not something that can be banged out soon. But, this will get a lot of frowns so in addition, you gotta speak the language of biz people. Make project and dollar predictions on why it will be better, in the long run, to do a better job in the beginning. When biz types start seeing dollar explainations, then they can start adjust schedules, contracts, etc.

    It's not hard to do, but it does take some dilligence and foresight. Like so many, I too have the urgency to just jump right in to something. But I've seen over time success is within reach when you, unfortunately, manage others expectations. If you cannot do this, then the people writing the checks will always have your balls in a vice.
  • Fact of line. (Score:4, Insightful)

    by litewoheat (179018) on Thursday July 10, 2003 @06:57PM (#6410713)
    The sad fact is "Quick and Dirty" wins the race while "Done Right" goes out of business (or has a fraction of the total market. Microsoft is "Quick and Dirty" Apple is "Done Right" (basically). For homework, compare the two companies.
  • The easy answer. (Score:2, Insightful)

    by Bluelive (608914) on Thursday July 10, 2003 @07:07PM (#6410781)
    From experience, Build something working, Call it a prototype to those who want it 'clean and proper' Call it a trial version to those who want to sell it. Basicly, the proper way is too expensive in the short run and it will push costs up. Just make sure that v2 is made clean and payed for by v1. (either by investors liking the trail, or actually releasing it to the market)
  • by TheRaven64 (641858) on Thursday July 10, 2003 @07:10PM (#6410802) Journal
    How about correct and quick? If you don't write clear code and document it well then any time you save coding will be eaten debugging. Either way it will take the same amount of time, and if you rush and skimp on the documentation then you'll have unmaintainable code as well.
  • Re:No easy answer (Score:5, Insightful)

    by paganizer (566360) <thegrove1@hotmai l . c om> on Thursday July 10, 2003 @07:15PM (#6410840) Homepage Journal
    What about my experience, then...
    You work for a government contractor on a project for the army.
    You quickly discover that one of your coworkers is putting code in place on production servers that is VERY nasty, buggy, full of gaping security holes, but slightly more often than not, actually does the job that needs to be done.
    You get with your supervisor to point this out, let them know that security standards are being completely ignored, crash recovery (done by another group) is taking more time than doing it right in the first place.
    You and the REST of the team get let go, while the quick n' dirty guy gets promoted; the Army has to nearly triple the size of the group doing recovery.
    Grrrr.
    I may be blackballed by EDS, but I would never, ever, ever consider working with or by those scum sucking pigs again.
  • Re:No easy answer (Score:4, Insightful)

    by jafac (1449) on Thursday July 10, 2003 @07:28PM (#6410951) Homepage
    with layoffs coming every couple of months, I sure as heck don't want to be tech lead on a project that customers are returning and suing us over because it doesn't work as advertised.
  • by RDFozz (73761) on Thursday July 10, 2003 @07:33PM (#6410991) Journal
    First, as someone else in this thread stated, the first version of whatever you crank out, no matter how well-thought-out, isn't going to be ideal. Until the product has hit the real world, and real people have used it to perform their work, there will be unidentified inadequacies, design problems, shortcuts needed, etc.

    I always approach things from the "Do it right" perspective -- initially. I figure out what seems to be the best approach to resolve the problem. Admittedly, part of "best" does involve budgetary issues - on a shoestring budget, "best" can't include hundreds of thousands (or even tens of thousands!) of dollars' worth of high-end hardware and expensive software, and that's unlikely to change even over the course of years, in most cases.

    Once I've decided the "best" solution, I look at how clean I can make a solution that fits into the budgetary constraints I'm working in. Lay the groundwork for versions 2 and 3, as long as it doesn't prevent you from reaching your version 1 goals.

    Now, it doesn't necessarily pay to be to lay that groundwork too extravagantly; as noted earlier, at least part of version 2 will be responding to the comments, complaints, and critiques of the users of the system. Unless you have the luxury of spending an extensive amount of time with end users, getting their input on everything from validation, auto fills, and screen layouts to the color schemes to use, there will be requested changes.

    Also, remember that you're almost always serving two masters; the end user who sits in front of your creation, and the guy who signs the checks. If you want to finish the project, the check guy has to be happy; if you want to get more work down the road, the end users better be happy.

    Ultimately, communication is key. As others have said, document what will and won't get done, and get sign-off on it. When (not if) the client wants to change things, point to the contract that either says that the delivery dates will changes or that changes will be made after everything on the current approved timeline is complete, and that the client will pay when things change.

    You're stuck in the middle of everyone using the various aspects of the program (not to mention the people writing those precious checks), so take on the role of middleman fully. If the end users convince you that something is required, discuss it with the check people until they either understand why it's needed or make it clear they don't care why. Do you best to make sure the client understands why you recommend against a particular course of action. Document when they choose to ignore such advice. Then do what they want (barring ethical/moral/legal issues - only you can decide if you're willing to get fired (maybe "blacklisted") over what's going on).

    In short, pull as close to "do it right" as you can, and try to make it as easy as possible to come back later and fix the "quick and dirty" parts, if you can. And make sure everyone knows what's what.
  • by 0-9a-f (445046) <drhex0x06@poztiv.com> on Thursday July 10, 2003 @07:39PM (#6411042) Homepage
    There's small business, where Quick'n'Dirty is literally the difference between Life now, or a slow and lingering Death. But either way, you're still around for a bit longer.

    There's mid-sized business, which is (hopefully) either growing too fast to know what it's really doing, or comfortably well-off (established products and/or customers, etc). If it's growing fast, Quick'n'Dirty is again the only way, because otherwise the momentum stops and you risk the whole house of cards crashing down.

    If you're a comfortably established mid-sized business, or larger, then you really have to focus on keeping what you've got. Customers will leave if you don't look after them, and products will die if you don't maintain them. The only two uses for Quick'n'Dirty are:

    1. QADFIP - The Quick And Dirty Fix-It Program, that overcomes a glaring error, or sudden change in requirements.

    2. A competitor falters, and marketing have one chance - THIS WEEK! - to pick up their customers. See number 1.

    If you deploy a QADFIP, the PHBs need to understand that it is a QADFIP, and that you willl spend the next week (or so) cleaning it up TO KEEP THE CUSTOMERS it won you.

    To use Quick'n'Dirty programming under any other circumstance is self-defeating - and you will find yourself ultimately accountable for your actions, regardless of who told you to do it.

    Remember - you did it, not that loser in marketing.

  • Re:No easy answer (Score:2, Insightful)

    by Milo77 (534025) on Thursday July 10, 2003 @07:49PM (#6411108)
    One of the problems is that MS has conditioned their customers to tolerate crappy software. As a result other companies can also get away with releasing software of poorer and poorer quality. In capitalism, it is all about what the market will bare, and currently it will bare bug-ridden software. And all the MBAs have been trained to push the envelope on what the market will bare. If they can get away with shorter release cycles and buggy products then you'd better believe that's exactly what they'll do...and hey, my stock options keep going up, so what do I care ;)
  • by ChrisCampbell47 (181542) on Thursday July 10, 2003 @10:58PM (#6412106)
    • Fast
    • Good
    • Cheap
    Pick two.

    Keep it in mind, and you'll be amazed at how it applies to everything.

  • Re:Read history. (Score:2, Insightful)

    by Eccles (932) on Friday July 11, 2003 @01:35AM (#6412752) Journal
    I also think that you will have a very difficult time finding EVEN ONE that would be described as successful by any reasonable person and has survived until today.

    How about the Israeli Kibbutzim? Some are ~100 years old...
  • by Anonymous Coward on Friday July 11, 2003 @03:18AM (#6413056)
    There are 2 extremes of programmers: idiots and idiots. Everyone else falls somewhere in between.

    Half the idiots are the ones who absolutely believe that their 5 years of industry experience qualifies them to be sole judge of absolute right and wrong in things such as languages, technology, coding style, etc. These poor souls believe that all engineering should adhere to strict policies regardless of business timeliness. These idiots tend to demand schedule delays in favor of constant pursuit of architectural and stylistic perfection.

    The other half of idiots see no value in structure and discipline. These tend to be people who abuse XP and will always do only the bare minimum. They produce spaghetti code and are frequently strange people who have absolutely no regard for best engineering practices whatsoever. These guys always deliver utter crap on time and the working version 2 months before the company goes bankrupt.

    Then there are the in betweens - the rest of us. Those of us that can be flexible know when to deliver the fast, spaghetti code to land the customers. We know when to architect things for long term efficiency. And we know that usually, a good engineering team is a steady balance of these two. We know that engineering is a constant cycle of research, plan, code, refactor.

    So, to answer the question: if you're in that situation, unless you have faith in the people around you, quit. Chances are, you'll deliver the goods, save the company, only to have some self-proclaimed "god" of programming tear your code to shreds for being sloppy, make a fool of you, and never actually have to deliver under the same conditions.

    Face it, you're doomed.
  • by Taco Cowboy (5327) on Friday July 11, 2003 @03:36AM (#6413110) Journal


    While your case may not be an isolated one, the fact that dirty hacks bring in money, while properly documented one doesn't speaks volume on the correct (or rather, the lack of) implementation of programming practices at the place you work.

    No, I am not preaching stuffs like "Extreme Programming", but documentations is a must if we really want to tame the insanity of what we do - and programming itself is one of the quickest way to insanity.

    I do know that documentation takes time, but if you put in an effort on document what you write, the time invested on documentation WILL pays off many, many times when it comes time to extend / alter or debug the code that we have done, be it 3 days or 3 years ago.

  • Old, old adage (Score:5, Insightful)

    by Rogerborg (306625) on Friday July 11, 2003 @04:45AM (#6413239) Homepage
    There's never time to do it right, but always time to do it twice.
  • by freddled (544384) on Friday July 11, 2003 @04:52AM (#6413253) Journal
    Most organisations have Just * Do It Person and Process Junky Person. As a software engineer you have to manage the balance.
    • If you live at the process junkie end of the spectrum, the software that you create is very expensive and may actually never get to the market.
    • If you live at the extreme end of JFDI space then the chances are your company will make money this year and then die the death of a million user group quality flames.

    When I have to cope with JFDI this is what I do.
    • First, don't cut off future improvement. It should be obvious but there is a fundamental difference between putting out a bowl of spaghetti and putting out a minimal solution with extension points.
    • Don't panic. Design reduces coding time, always. I don't care if you are talking about ten person years coding or two hours at 3am. Designing the solution always reduces coding and testing time. It also improves quality and therefore reduces your rework when the bug reports come in. If you have to fix lots of production bugs, extending your solution to meet Process Junkies idea of minimum quality will never happen.
    • Defend yourself. JFDI can't tell you to go straight to the code. This is a big problem, but ultimately JFDI should be managing the crisis that has led to the urgent requirement, not hassling you for scribbling designs instead of cutting code. Also, find out what JFDI is going to do for you when you solve their problem before you solve it. It doesn't always work, but we have all worked all night for someone who doesn't say thank you, or criticises the solution. Personally, I look for a written/email request for me to pull out the stops, stating a business need. Bombarding JFDI and PJ with emails at hourly intervals around the clock also helps drive home the point. Remember, JFDI person has that role because they aint subtle.
    • Think like the CFO. These guys want revenue and increased earnings per share this quarter. Future quality issues are secondary and, in some cases, are seen as a source of future revenue. JFDI cuts cost and therefore increases earnings per share. Instilling future quality and maintainability is fundamentally something that you do to make your job more satisfying, easier and professional. Only you and Process Junkie Person care about that. JFDI doesn't because they get more crises to manage if quality falls. CFO/CEO don't. So, don't be naive about the management being on your side in this, you have to protect yourself.

    So, fundamentally, until Software Engineering is a formal profession with audits and minimal standards, until customers can sue software companies for negligence in their engineering process, quality is down to you. If JFDI calls, you have to build in the quality, or at least the potential to reach the quality threshold yourself.
  • by Arkan (24212) on Friday July 11, 2003 @05:33AM (#6413325)
    Just a few question for you Slashdot crowd:
    - why computer industry has to cope with such incredible decisions such as choosing between producing something good, or producing something quickly?
    - why computer industry has a so special place in our business world that practices that will be judged and punished as criminal (such as releasing a hazardous product, boast inexistent features, etc...) are so common that even Joe User doesn't care anymore?
    - finally, shoudln't we IT workers (from code-monkeys to gurus) throw PHBs, bean-counters and marketroids through the 100th floor windows?

    Maybe an beginning of the answer to the above question: other arts, craftmanships and industries have been around sometimes for centuries, and people working in this fields inherit the respect due to such ancient arts. But computer industries (both software and hardware) were born in an age dominated by money, where quality comes second to profit, and never had a chance to win the required respect to such critical appliances.

    --
    Arkan
  • by Lil'wombat (233322) on Friday July 11, 2003 @03:41PM (#6418397)
    The basis for your question is your belief that the quick solution will bring in the revenue/land the contract/ whatever.

    I think that assumption is wrong and here is why:

    Outside of new economy / dotcom era, things really don't move that quickly in the business world. I work for a fortune 300 company and we are lucking to make a decision about anything less than 60 days. I used to do government contracting and that was 1-2 year contracting sales cycle.

    Bottom line if your customers are existing/established businesses, then there are rules in place to prevent anyone from spending lots of money quickly. So time is always really on your side. Even when sales and marketing say that something is a done deal, its a go, we starting right now, it will probably be weeks before contracts are signed and checks cut and expenses authorized.

    Stop believing the lie that everything has to happen NOW, NOW, NOW.

    And ask your self, if the sucess or failure of your company is dependent on feature X being availble right now, why wasn't that identified long before this crucial moment? Whose doing the product development? Who is gathering requirements in advance of customer need? If your customer base is still in the fast and furious mode are they long for this world? If your company doesn't have a long term plan and is just reactionary are they long for this world?

Bus error -- please leave by the rear door.

Working...