Slashdot Mirror
"Quick 'n Dirty" vs. "Correct and Proper"?
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)?"
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
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.
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.
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.
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.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
What you describe is not a social problem - it is a human nature problem.
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.
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.
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.
Laws are for people with no friends.
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.
Auto-reply to ACs: "Truly, you have a dizzying intellect."
You sure you actually improved it then?
Clearing major changes with your cowworkers is generally a good thing.
How small a thought it takes to fill a whole life
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
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.
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
O'WONDERWe're working on it.
So he did the right thing.
And yet, he offers this testimony later:
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:
The answer is simple: It's not your call. Don't make it.Easy, automatic testing for Perl.
Problem is, they actually want to see both 'out quick' and 'well engineered', even if it's not possible.
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"
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.
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!
--==-- I've found Karma to be a relative thing... Ya know, the kind you invite to Christmas...
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.
R David Francis
There's never time to do it right, but always time to do it twice.
If you were blocking sigs, you wouldn't have to read this.