Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
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"? More

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

Comments Filter:

  • You just found out that your father, who is in perfect health and has raised you for as long as you can remember, is not your real father. Your real father is somewhere, nobody knows where, and either dead or nearly so. The feeling that you get imagagining that scenario is the reason that I strive to ensure information never dies. It's why I cry when I see a house torn down, and it's why I cry when I think of the fathers of my chosen discipline dying off one-by-one, leaving behind only what programs and books they've managed to produce. And it's why I'm scared that one day I'll wake up and find that there's a piece of me, the fruit of my heart and mind, my program, my son, that, if I don't track it down, will be lost forever.

    Passion! Passion is the key! If we are passionate about everything we do, we leave behind a wake of people inspired by our passion, inspired not by what we've done but by *how we've done it*. Passion yields fruit so ripe, its benefactors need remember only our name, because they can but speak it to a person who has known us, and the passion comes alive from us through them! Passion, not persistence, not training--not any of those things, though they are certainly important. Nothing but passion can lead us through to a place where our name connotes the good, endorses the worthy, and gives rise to those not only capable of following in our footsteps, but with their *own* passion, born of ours, to do so right.

    Passion is the key. Be passionate now. If you aren't passionate about what you have written, if you aren't fighting the irresistible urge to hold it up high and have the world marvel at its brilliance and beauty... then you have failed, and you mustn't release that code.

  • One reason why we need to absolve money (Score:3, Interesting)

    by suso ( 153703 ) on Thursday July 10, 2003 @04:57PM (#6410131) Journal
    This is one reason why we as a society need to find ways to get rid of this need for greed and wealth and money in general. Otherwise things just keep running into the ground.

  • No easy answer (Score:5, Insightful)

    by bartlog ( 154332 ) on Thursday July 10, 2003 @04: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.

    • Re:No easy answer (Score:5, Interesting)

      by GordoSlasher ( 243738 ) on Thursday July 10, 2003 @05:15PM (#6410370)
      And with layoffs coming every couple of months, I sure as heck don't want to be tech lead on the project that missed its market window because I insisted on perfection. I try to balance risk/reward, taking shortcuts on the less risky parts, negotiating to eliminate unnecessary functionality, and doing whole-hog process on critical system components.

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

        by paganizer ( 566360 ) <thegrove1&hotmail,com> on Thursday July 10, 2003 @06: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 @06: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.

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

      by geekmetal ( 682313 ) <vkeerthy@LIONgmail.com minus cat> on Thursday July 10, 2003 @05: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.

    • Re:No easy answer (Score:5, Interesting)

      by sm1979 ( 558600 ) <sebastian@muelle ... al.net minus cat> on Thursday July 10, 2003 @05:31PM (#6410511) Homepage
      I can only speak from my experience at my current employer. The company is founded by two CS PhDs, so no PHB trouble. We don't follow any formal process in our development, we don't even comment the code, which really pissed me off in the beginning. However, what we do rather successfully is to make everything as simple as possible.

      If you run over some code and you figure it could be done simpler, even if it's not your code, do it simpler NOW. If you find something has been done in a quirky way, fix it NOW. The general rule is that the code has to be understood for the next let's say ten years. We have strict coding guidelines regarding method naming and variable naming. If names are not fully self-explanatory they are replaced immediately even if they're scattered through the whole application. If critical parts like persistence suffer from a bad architecture, it is fixed immediately no matter how much work the rewriting involves. Finally, this leads to very understandable code and once you've understood the general application architecture the code is very easy to read, very clean and mostly pretty correct. There are hardly any quick hacks, sometimes they are inevitable though, to circumvent bugs in the software environment for example.

      If you're suffering from lay-offs and don't mind 170 days of rain per year, consider think-cell [think-cell.com] (I'm only a student employee myself, neither owner nor partner, so it's not advertisement, just advice).

      • Re:No easy answer (Score:4, Interesting)

        by cfulmer ( 3166 ) on Thursday July 10, 2003 @08:52PM (#6411777) Journal
        UGH... Talk about all the wrong things to do! The idea of fixing problems early is good, but your method of doing it sounds to be out of control.

        There's no better way to guarantee that your product will never congeal than to be constantly changing it. What happens when the quirky code you just changed 5 minutes ago had just finished a month of testing and debugging? Or when your architectural re-write has a chain-reaction further downstream?

        One of the most important things that good software development companies do is to track their defects, figure out where they came from and develop a plan for fixing them (or not...)

        In the Apollo space program, the astronauts had a listing of every known bug in the computer software and what they needed to do when that bug got hit. You may ask "If they knew where these bugs were, why didn't they fix them?" It's a good question and I believe that the answer boiled down to "Because then you'd be introducing a bunch of bugs that you didn't know about."

        Remember the time-money-quality (pick any 2) triangle.

    • Re:No easy answer (Score:5, Informative)

      by C60 ( 546704 ) * <saladNO@SPAMcarbon60.net> on Thursday July 10, 2003 @05:36PM (#6410563) Homepage
      You're right, there is no definite answer to this question, however there are some ways to create a balance.

      Keep in mind, this works best if you have a good dev team, a bit longer of a development timeline, and have management that understands the Q&D vs proper arguement. Or at least can be made to agree to it.

      First off take the time to sit down with the development team, and make a project timeline. Use Gannt charts, management loves that, and it adds a real sense of professionalism to your dev schedule.

      In developing your timeline, identify the "low hanging fruit" (a term I despise) which can be quickly adapted from existing code, as well as the items that both can, and cannot be written Q&D. Next, add in re-engineering of the Q&D sections of code to the timeline. Make sure that you find a balance where you have enough items developed early on that the PHBs have something to sell and boast about. It also helps if you make sure you don't do everything Q&D.

      Stick to the timeline

      If for some reason you can't, bring it up with the PHB and adjust the timeline.

      A realllllly good way to make this work is to set out a bonus schedule for completion of certain phases of development before a certain time. This takes having a cool PHB, but it's a great way to keep motivated.

      This is the way my last major dev project worked. And it worked *Very* well. Every phase of the project resulted in something the PHBs were happy with and could sell. As a developer and team leader I got a bonus for making sure my code was delivered on time. We even had a discretionary bonus pool that we could use to reward people who made an outstanding contribution to the project.

      The real key here is to communicate with the PHBs, using their language (gannt charts), make sure you keep control of the development timeline, and most of all, stick to that timeline.

    • Plan it right, do it close, think "Phase 2" (Score:5, Insightful)

      by RDFozz ( 73761 ) on Thursday July 10, 2003 @06: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.

  • It's like sex... (Score:5, Funny)

    by PeteyG ( 203921 ) on Thursday July 10, 2003 @04:59PM (#6410146) Homepage Journal
    It's like sex.

    Quick and dirty, like getting drunk and meeting some stranger in a motel room, will leave you feeling gross aftewards.

    Correct and proper, like wooing a nice and attractive young lady, takes time, hard work, and if it works out, leads to something wonderful and long-lasting.

    Either way, you have sex. But which one would you rather tell your mother about (or rather, put on your resume)?

  • Correct and Proper (Score:4, Insightful)

    by dylan95 ( 307651 ) on Thursday July 10, 2003 @04: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.

    • 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.

      But you'll be RICH

    • 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.

  • Always Document Approval (Score:4, Insightful)

    by Anonymous Coward on Thursday July 10, 2003 @04: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.
    • Is it your decision?

      It sounds like it isn't your decision to call either way. So make sure you provide all of the information, including what the negatives will be, for both methods, then let the people who're paid to decide, decide.

      Sometimes, whether we like it or not, whether it suits our meticulous geek processes, staying in business and dealing with shit down the line is a better option than doing it right and going out of business. It's that old line: I can do it fast, cheap or well. Pick any two. In

  • $uccess is temporary (Score:5, Insightful)

    by mrybczyn ( 515205 ) on Thursday July 10, 2003 @04: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.
    • 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.

    • Re:$uccess is temporary (Score:5, Insightful)

      by sparkhead ( 589134 ) on Thursday July 10, 2003 @05: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.

  • I think for the few truly excellent programmers: (Score:5, Funny)

    by ath0mic ( 519762 ) on Thursday July 10, 2003 @05:00PM (#6410163)
    "Quick 'n Dirty" == "Correct and Proper"

    ...and believe me, I'm not one of them.

  • Whats a process ? (Score:5, Interesting)

    by shaka999 ( 335100 ) on Thursday July 10, 2003 @05:00PM (#6410164)
    At least well I work process is what everyone agrees we should be doing. We are never, NEVER, given the time to completely follow the process. If you try you will either be working 60+ hour weeks or laid off for missing schedule too many times.

    What I find funniest about our development process is that the people most adamant about putting things in place and documenting developement usually aren't having to do all the grunt work they are suggesting.

  • *Cough* *Cough* (Score:5, Funny)

    by buffer-overflowed ( 588867 ) on Thursday July 10, 2003 @05:00PM (#6410167) Journal
    Clicky Clicky. [lysator.liu.se]

    Truly, things to program by (or not).

  • Personally (Score:5, Insightful)

    by elBart0 ( 444317 ) on Thursday July 10, 2003 @05: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.

    • Re:Personally (Score:3, Interesting)

      by haystor ( 102186 )
      The time and cost required to meet various goals, minus the opportunity costs of meeting previos goals at those quicker and dirtier levels of effort.

      Every day I'm more convinced that quick and dirty is better because it gets code written which means it can be tested and often that means finding some aspect of the way the business is *really* run that was previously unknown.

      Of course, I work doing business programming. If I drop one order a month at $40 that's no big deal really. Customer service will ca

  • Do it right. (Score:5, Insightful)

    by nuggz ( 69912 ) on Thursday July 10, 2003 @05: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.

  • Quality will be rewarded in the end (Score:3, Insightful)

    by whistler36 ( 189652 ) * on Thursday July 10, 2003 @05: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.

  • Get the sale (and prepare for doing things right) (Score:4, Interesting)

    by burgburgburg ( 574866 ) <splisken06&email,com> on Thursday July 10, 2003 @05:01PM (#6410190)
    Any down time should be used to create the circumstances so that a proper procedure solution can be quickly, cleanly applied. For now, though, get the damn sale. If you're around long enough (and anyone still cares), you can fix it later.

    That said, quick and dirty is always more fun.

  • Maintenance Contract (Score:5, Insightful)

    by Crashmarik ( 635988 ) on Thursday July 10, 2003 @05: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.

  • Prove yourself first (Score:3, Insightful)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Thursday July 10, 2003 @05: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 =)

  • Change your process (Score:3, Insightful)

    by SlashdotLemming ( 640272 ) on Thursday July 10, 2003 @05: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 :)

  • Scott versus LaForge (Score:5, Insightful)

    by SunPin ( 596554 ) <slashspam AT cyberista DOT com> on Thursday July 10, 2003 @05: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.

  • Quick and Unemployed (Score:5, Insightful)

    by Liselle ( 684663 ) <`slashdot' `at' `liselle.net'> on Thursday July 10, 2003 @05: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.

  • Depends, of course. (Score:4, Insightful)

    by IthnkImParanoid ( 410494 ) on Thursday July 10, 2003 @05: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.

  • Money.... It's really all about the money... (Score:3, Interesting)

    by Rahga ( 13479 ) on Thursday July 10, 2003 @05:11PM (#6410335) Journal
    ... and to be honest, this isn't your concern.

    You see, if marketing folk and PHBs aren't heeding your warnings about quick-and-dirty solutions, and are telling potential clients that the sun will always shine and everything your company touches turns gold, then it is their responsibilty to deliver on those promises, not yours.

    See, this is where that paperwork everyone always whines about comes in handy. Get rid of the bull ("synergy","integration", and oter hot words), keep from overdocumenting the situation, and make those "little notes" availiable wherever you go. Just do the jobs you are given, know your role, and give your tormentors no choice but to live up to their roles.

    As far as dirty-vs-clean.... Bah... You really don't need opinions on that now, do you? Just give yourself a bit of backbone, man. :)

  • Speaking from experience... (Score:4, Insightful)

    by Chicane-UK ( 455253 ) <chicane-ukNO@SPAMntlworld.com> on Thursday July 10, 2003 @05: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!

  • For What It's Worth, A Few Suggestions (Score:4, Informative)

    by Shackleford ( 623553 ) on Thursday July 10, 2003 @05:16PM (#6410376) Journal

    Just out of curiousity, why was this not put in the "Ask Slashdot" section?

    Anyway, even though I can't really say that I have had that sort of experience very often, but I'll do what I can to give a good answer to this question. I certainly hope that I won't find myself in these kinds of situations, although perhaps I'm being too optimistic. I understand that this happens quite often, and so I'm sure that you're not alone.

    Anyway, while I can't suggest much, I doubt that many other people can. It's hard to get the PHBs to listen to you when you say the Q&D style solutions will only save time and money in the short term. If the anecdote that you gave is true, then maybe those PHBs will learn their lesson and not demand that so many shortcuts be taken. Shortcuts make for long delays, as they say.

    I suppose that the best thing you can do is find ways to convince them that your ideas are worth listening to. As a matter of fact, a book titled The Pragmatic Programmer [amazon.com] not only goes into detail about good software practices, but how to convince those PHBs and fellow team members to listen to you. I suggest taking a look at it.

    So anyway, good luck. This problem won't be easy to solve. Keep working on getting people to listen to your ideas and why it would be better than the Q&D approach in the long run. That's what I say.

  • Worse is Better (Score:5, Informative)

    by Karna ( 80187 ) on Thursday July 10, 2003 @05:19PM (#6410401)
    A classic paper [stanford.edu] on the fact that sometimes solutions that are incomplete and do not cover all cases are superior and preferable to a "perfect" solution. Examples you say:
    • Unix v/s ITS (from the paper)
    • C v/s Lisp (from the paper)
    • Linux v/s Hurd
    • Opteron v/s IA64

    • Re:Worse is Better (Score:3, Interesting)

      by Cthefuture ( 665326 )
      This is basically the philosophy of Extreme Programming.

      And my answer to the "Quick 'n Dirty" or "Correct and Proper" qustion is to use some or all of the Extreme Programming practices. I had been using some of those XP techniques way before anyone decided to define what XP was (mostly from hands-on programming experience over the last 20 years) and have found it provides a great balance between a perfect design and something that "just works". Having something that works is way, way more important than

  • HTML or Assembly? (Score:5, Insightful)

    by stevejsmith ( 614145 ) on Thursday July 10, 2003 @05: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 @05: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

  • What I do (Score:5, Interesting)

    by MarkWatson ( 189759 ) on Thursday July 10, 2003 @05:25PM (#6410468) Homepage
    Over half of my consulting jobs are in the "quick as you can" mode.

    I make the effort to point out the pros and cons of spending more time - then let my customers decide what they want.

    However, one thing that I do (for the quick jobs), is to send my customer a very short email (after agreeing on how the project will be done) summarizing our agreement to do a "quick as you can" project. Then, at the end of a project, I re-send the same email - remind them what they agreed to!

    The same technique should work if you are an employee at a company.

    Sometimes it is correct to do a "quick as you can project" - other times it is better to go for maximum quality. A quick project should produce correctly running code, but will be more difficult to maintain and modify in the future.

    -Mark

  • The answer is simple: It's not your call. (Score:5, Insightful)

    by tmoertel ( 38456 ) on Thursday July 10, 2003 @05: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.

  • It's a question of optimization (Score:5, Insightful)

    by Xeger ( 20906 ) <slashdotNO@SPAMtracker.xeger.net> on Thursday July 10, 2003 @05: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.

  • Both! (Score:5, Insightful)

    by RandyF ( 588707 ) on Thursday July 10, 2003 @05: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!

  • Fact of line. (Score:4, Insightful)

    by litewoheat ( 179018 ) on Thursday July 10, 2003 @05: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.

  • Edsger W. Dijkstra opined on this subject... (Score:5, Informative)

    by stienman ( 51024 ) <adavis&ubasics,com> on Thursday July 10, 2003 @06:56PM (#6411148) Homepage Journal
    "Being a better programmer means being able to design more effective and trustworthy programs and knowing how to do that efficiently. It is about not wasting storage cells or machine cycles and about avoiding those complexities that increase the number of reasoning steps needed to keep the design under strict intellectual control. What is needed to achieve this goal, I can only describe as improving one's mathematical skills, where I use mathematics in the sense of "the art and science of effective reasoning". As a matter of fact, the challenges of designing high-quality programs and of designing high-quality proofs are very similar, so similar that I am no longer able to distinguish between the two: I see no meaningful difference between programming methodology and mathematical methodology in general. The long and the short of it is that the computer's ubiquity has made the ability to apply mathematical method more important than ever."
    prof. dr. Edsger W. Dijkstra - EWD1209 [utexas.edu]

    -Adam

  • Pick your battles (Score:3, Interesting)

    by keyslammer ( 240231 ) on Thursday July 10, 2003 @08:32PM (#6411684) Homepage Journal
    I've been doing software for a long time now (13 years, professionally) and I've seen some of my cleanest, best documented designs go almost unused, and some of my quickest, dirtiest hacks grow into the cornerstones of the system.

    Software development is about dealing with change. Requirements change. Technologies change. Business plans change. Development teams change. Sometimes when we try to do the right thing, plan everything out, document it, create clean interfaces instead of holes in the wall... what we're really doing is betting against change, and that's always a longshot.

    The best way to design, IMHO, is to start with a few good quick hacks that solve the bulk of your problems. Then put it into production and let the feedback tell you what you need to do. What do the users like? Where is the redundant functionality that merits adding infrastructure? What parts of the system are most problematic? We never really understand what we develop until we've had to build on it for two or three generations.

    So my advice is leave your hack in place. If you have to change it a month from now, and then a month after that, that's a good sign that it's something that's worth doing right. If not, then your hack was the right thing to do, after all.

    If you want to insulate yourself against getting slammed in the face by that hack, the best investment of your time is to write some good test suites. This way, if you add something that breaks your hack, you know about it quickly.

    Just my little contribution to the background noise :-)

  • "Q&D" is an important tool (Score:4, Informative)

    by dcavanaugh ( 248349 ) on Thursday July 10, 2003 @08:51PM (#6411765) Homepage
    Not to be overused, of course, but consider the advantages:

    1. You have the ability to launch a project in the absence of a complete specification. If your customer is truly unable to describe what they want (until they see a Q&D system that gets part of the job done), then what is to be gained by dragging out the specifications process until any potential benefits have been lost? At the end of the day, the PHBs get the impression that "Our IT people couldn't get it done."

    2: You have the built-in escape from a failed project. "This is just a prototype system that will help us build the specifications for a REAL system later... Let's deploy this little toy and learn from the experience." Of course, there is a very real chance that the "prototype" goes into real production. But if the project sucks, then it's super-easy to activate spin-control and launch the formal design of the "real" project. What is the escape route when you are $150K into the design/planning process and you suddenly realize that the goals are unattainable?

    3. Consider the world of rapidly changing requirements, where the target moves faster than the geeks can write code. When does the traditional process catch up with the latest requirements? NEVER

    4. Although documentation suffers, this is not always a bad thing. It certainly creates a dependency on the people who delivered the project, especially after a few of these little "science projects" are performing mission-critical tasks. Ask some of the currently unemployed geeks how their formal project plans and documentation made their employers feel safe in cutting the IT dept.

    5. We have competitive issues arising from offshore outsourcers, and H1B labor. If there is one method that these people are in no position to emulate, it is the "Q&D, design while build" technique. The time zone and language barriers are both show-stoppers for Q&D projects.

    Maybe the PHBs would stop looking to squeeze every IT dollar if we simply delivered useful projects a bit cheaper and alot quicker, even if the quality is not precisely as we might like. Hell, it sure works for Microsoft!

    The Q&D method is inappropriate for large projects or inexperienced staff. There are skills for "guerilla tactics" that not all developers or managers have. Not every problem should be handled with Q&D methods, but there is a time and place for this kind of thing.

    Which is the more satisfying job: leading a small group of IT commandos and attacking relatively small targets, or leading an army of morons in a war of attrition, armed with a 3-inch thick plan that is riddled with inconsistencies?

    Years ago, I remember insisting on a formal approach and getting mostly criticism in return. Now I am flexible. Experience has shown me that I have to put aside professional pride when the immediate interests of my customer are better served by a band-aid approach. It's all very simple: If we take care of our customers, then we create positive karma, and some of that comes back to us. If we miss an opportunity to take care of a customer, then the competition takes care of them for us. Nobody was ever promoted because they held back a project until the specs and docs were complete. The risk of a missed opportunity is sky-high, whereas the risk of a half-assed project is often manageable, especially if the cost is kept low.

  • Engineering Rule #1 (Score:4, Insightful)

    by ChrisCampbell47 ( 181542 ) on Thursday July 10, 2003 @09:58PM (#6412106)
    • Fast
    • Good
    • Cheap
    Pick two.

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

  • An example priority list (Score:5, Informative)

    by MightyDrake ( 612329 ) on Friday July 11, 2003 @02:55AM (#6413154)
    Several years ago, a guy on a Compuserve forum listed the seven facets he prioritizes at the beginning of every project. (I no longer have the post, so I can't give proper attribution, and these will be from memory.) He suggested that they should be considered and rearranged for each project. On any given project there will be two or three that stand out as particularly important.

    1) Time to market
    2) Cost to develop
    3) Maintenance
    4) Correctness/reliability
    5) Performance
    6) Extendibility/architecture
    7) Features (or can a subset be used for the initial release)

    At the beginning of the project the decision makers need to sit down and order this list for that particular project. Whenever it comes time to make a decision or tradeoff, they should compare it to the priority order determined for the project. If the tradeoff violates one of the top priorities then it should be considered with great care.

    Some examples:

    - In a PC flight sim game, Time to market and Cost to develop are probably the top two, and Features, and Performance are a little lower. Since game engines tend to turn over so quickly Maintenance and Extendibility are less important. And Correctness, while nice, really is one of the least important priority items (above a minimum reliability, of course.)

    - In contrast, in an FAA flight training sim Correctness is probably the most important followed closely by Performance (mostly as it applies to Correctness.) Maintenance and Extendibility would prolly be important to a company that's building sims for a family of aircraft. But it might be less important for a company that's building a sim for a one-off class of aircraft such as a fighter. (Albeit, the ability to add new weapons systems and threats might bump this up.) Time to market and Cost to develop end up having to just fall out from the higher priorities.

    - For many business applications, Maintenance tends to dominate the cost of using an app. For mission critical apps Correctness probably rivals Maintenance for top spot. And the rest will depend on the particular project.

    And so on. As I said, I may be mis-remembering one or two of those priorities. But the general idea is valid. A list like this can help a team spell out ahead of time what's imperative, against which they can measure their decisions.

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

    by Rogerborg ( 306625 ) on Friday July 11, 2003 @03:45AM (#6413239) Homepage
    There's never time to do it right, but always time to do it twice.

Slashdot Top Deals

To be or not to be, that is the bottom line.

Close