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.
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)?
no thanks
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.
Clicky Clicky.
Truly, things to program by (or not).
The key to the enjoyment of pop music is to replace any instance of "love" with "C.H.U.D."
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.
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."
All weakness is within you, As is all courage.
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.
Typical development cycle is from 6 to 18 month. If public companies reported once a year there would be less pressure to "close a quarter" and less pressure to do shoddy work for that on elast deal.
<^>_<(ô ô)>_<^>
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
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Faced with a choice between "quick and dirty" versus a long process that is not even ready to produce code until everything is known, there isn't a company in the world who won't go with quick and dirty.
The long elaborate process doesn't really work anyway. The world changes too quickly.
What you need is a methodology which emphasizes development in stages. XP (Extreme Programming) and Feature Driven Design (a variant of UML) are two examples.
The important thing is to identify your fundamental interfaces, make sure those are right. Document them. And then feel free to code each and every component as "quick and dirty" as you ever imagined.
If you did the first part right, you can replace components later, add new components, etc.
If you didn't document your interfaces well... you've just delayed the failure of the project through absurd amounts of overtime. You have zero chance of longterm success.
It isn't even necessary to always have a grand master plan. Well documented simple interfaces can frequently be extended in ways that weren't anticipated when they were first created. But you have to focus on the interfaces - that's what allows for evolution.
The most obvious example of this is the Internet itself. The OSI stack was trying to do things "thoroughly", IP just wanted to be "flexible". Flexible can be developed cheaply, and unlike either pedanticly thorough methodologies or complete anarchy, has a chance to build itself up one useful piece at a time.
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.