"Quick 'n Dirty" vs. "Correct and Proper"? 887
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)?"
No easy answer (Score:5, Insightful)
Correct and Proper (Score:4, Insightful)
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.
Always Document Approval (Score:4, Insightful)
$uccess is temporary (Score:5, Insightful)
Professional Software Tester's Opinion: (Score:1, Insightful)
Quick and dirty solution:
$1000 to make
$100000 to support
or
Proper solution:
$10000 to make
$10000 to support
Personally (Score:5, Insightful)
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.
it's not that simple (Score:2, Insightful)
Sometimes quick and as proper as possible (but mostly quick) is your only option.
Re:One reason why we need to absolve money (Score:5, Insightful)
Do it right. (Score:5, Insightful)
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)
Re:Being the market leader (Score:3, Insightful)
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)
"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...
Maintenance Contract (Score:5, Insightful)
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.
Microsoft have already answered your question. (Score:2, Insightful)
Prove yourself first (Score:3, Insightful)
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)
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)
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.
Scott versus LaForge (Score:5, Insightful)
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)
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.
Re:It's like sex... (Score:3, Insightful)
Depends, of course. (Score:4, Insightful)
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.
there is always Quick & Clean (Score:1, Insightful)
Quick & Clean is possible
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
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)
are in, it will save you time and effort to have
a design document of some sort (even if its only
in your head)
unless you have a clear framework and path laid
down somehow
enough to Seem like you're just sitting down and
banging away
in your head
clean and proper code is art, and art can't be
rushed
piece more quickly than a fledgling
Re:Passion is the key - if you're passionate, rele (Score:5, Insightful)
You sure you actually improved it then?
Clearing major changes with your cowworkers is generally a good thing.
Re:$uccess is temporary (Score:3, Insightful)
Re:It's like sex... (Score:5, Insightful)
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
Re:$uccess is temporary (Score:5, Insightful)
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.
you answer your own question (Score:2, Insightful)
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.
Speaking from experience... (Score:4, Insightful)
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)
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
Do what you have to do... (Score:2, Insightful)
- Does it (the software) work?
- Does it (the software) do what it is supposed to do?
- 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)
Both! (Score:5, Insightful)
Re:No easy answer (Score:4, Insightful)
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.
The answer is simple: It's not your call. (Score:5, Insightful)
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.Re:Do it right. (Score:2, Insightful)
Solution:
Disciplined Development Requires Patience (Score:2, Insightful)
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.
Re:It's like sex... (Score:5, Insightful)
Problem is, they actually want to see both 'out quick' and 'well engineered', even if it's not possible.
Read history. (Score:2, Insightful)
Re:It's like sex... (Score:5, Insightful)
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"
It's a question of optimization (Score:5, Insightful)
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)
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)
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!
The small middle ground (Score:3, Insightful)
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)
The easy answer. (Score:2, Insightful)
Re:Correct and Proper (Score:3, Insightful)
Re:No easy answer (Score:5, Insightful)
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)
Plan it right, do it close, think "Phase 2" (Score:5, Insightful)
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.
What world are you working in? (Score:2, Insightful)
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)
Engineering Rule #1 (Score:4, Insightful)
- 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)
How about the Israeli Kibbutzim? Some are ~100 years old...
Well, I'll tell you what (Score:2, Insightful)
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.
Something is wrong if Quick & Dirty brings in (Score:3, Insightful)
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)
Managing JFDI person v process junky person (Score:2, Insightful)
When I have to cope with JFDI this is what I do.
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.
What's wrong with computer industry? (Score:2, Insightful)
- 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
Incorrect assumptions (Score:3, Insightful)
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?