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)?"
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.
Did you get that memo about the new cover sheets on the TPS reports?
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.
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.
Put together the quick & dirty solution, then fix and document afterwards when you have the benefit of time!
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
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.
Actually, there's different schools of thought. Your sister likes it quick and dirty - there's no doubt about that. However, your mother likes it when I take it nice and slow.
"Quick 'n Dirty" == "Correct and Proper"
...and believe me, I'm not one of them.
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.
One should not theorize before one has data. -Sherlock Holmes-
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
Now, hear me out, an don't mod me up as funny or down as a troll. :)
Microsoft often takes the quick-and-dirty way, and despite this, they've been successful, because, on the whole, their project is usable to end users. This should be what you strive for in business. If it works 95% of the time as a quick-and-dirty solution, then worry about fixing that 5% later when you have time. If the end users can get their work done without causing any potentially serious complications, why bother?
Of course, I also have to develop databases using FileMaker Pro. All I know is quick and dirty!
IAALS.
Unless your contracts allow "as long as it takes" as a deadline.
Sometimes quick and as proper as possible (but mostly quick) is your only option.
--
the strongest word is still the word "free"
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.
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.
That said, quick and dirty is always more fun.
Sorry, but I got terminated from my last position for having the gall to actually attempt to improve the product (without getting permission from all my coworkers who were out on Christmas vacation first). My take is that most managers would rather have developers that at least pretend to do what they're told, no more, no less.
"Freedom means freedom for everybody" -- Dick Cheney
I have to [somewhat] disagree here.
Usually the product that wasn't released within a market window fails. If your product is late out the door you don't stand a chance.
One should not theorize before one has data. -Sherlock Holmes-
George S. Patton Once Said...
"A good plan, violently executed now, is better than a perfect plan next week"
If its good enough for the US Third Army it must be good for Corporate America...
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.
Do it quick and dirty on the inside, make it look glossy on the outside. A short term fortune awaits...
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 =)
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
I say just drop the 'n Dirty and that's what you should do.
Do everything you can in (one of) the correct way(s), but as fast as you possibly can. Q&D solutions often reach up and bite you in the behind when you least expect them, resulting in wasted time trying to fix the "solution". Taking some amount of time (but not too much) to solve a problem is preferable if you ask me. But when you have people that don't have even the slightest inkling about what you are doing breathing down your necks... I can see where doing it dirty comes about.
.unsigged
When you do something quick and dirty, do you have
to maintain it? Or will that task be left to
some other poor slob who will bitch and moan
about the piss poor coding you did.
If you have to maintain it, do it right. You'll
be the person getting phone calls in the middle
of the night if you don't.
Of course you should always produce clean, well
tested code if you have any morals.
I guess the real answer is do the best you can
with what you're given. Make sure those in
charge know what you're doing and why you're
doing it. Are you, and your company satisfied
with the end result? If not, go back to start
and take a look at your methodology.
It reality only the government and
aerospace can afford true software engineering.
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."
As revolutionary as this might sound on Slashdot, there are times when it is the correct decision to give your boss all of the facts, and let him decide. The positive benefits include:
1) You are much less likely to get in hot water for making the wrong decision. It would take a truly malicious boss to hold you accountable for a decision that he/she made.
2) There is a reasonable probability that your boss will have a better sense of the urgency of the relevant business issues than you do, given his communication with upper management. If you can clearly present the technical pros and cons, he can weigh those against the business pros and cons in a way that neither of you could do without information from the other.
3) Lets you stop agonizing and get back to coding.
-Tupshin
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.
It's nothing but crumpled porno and Ayn Rand.
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
Why did I think of this Dilbert comic strip when I read your message?
simple. if quick and dirty is getting you "in hot water" after the fact, and you have to spend countless hours explaining why the q&d solution can't be the final one, you're wasting precious time that you could be using working on your proper and correct solution. try to find middle ground - find the happy medium between q&d and p&c. it's there, and most often won't be the same deal for different projects.
even if you're pressured to produce something - anything - that works in a short amount of time, at least have the foresight to put thought into it and plan for the need to do a partial redesign later. after your semi-q&d solution is released, begin working on turning it into as p&c as possible immediately. then when the phbs and marketroids come after you, you at least have something tangible to 'show' them.
Xfce: Lighter than some, heavier than others. Just right.
Think about it--why does the Open Source model produce better code? Easy--if the developer isn't happy with the code, it doesn't go in. If the other developers aren't happy with one developer's code, s/he loses commit access. And, let's face it, if you're not happy with the code, it's probably not fit to be in the product.
So, in many ways, whether or not you're passionate about your code is a damn good way to judge whether or not you've completed code worthy of actually making it into a product. Customers and managers win when their developers have passion for the code they've written.
Jouster
... 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.
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!
"Hey! Unless this is a nude love-in, get the hell off my property!!"
the pages stick togeather
Diplomacy is the art of saying "Nice doggie" until you can find a rock. Will Rogers
- 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.Spread the RC luvin'
So you have to ask yourself, what kind of organization do you want to be a part of?
The kind with jobs.
What the fuck's a TPS report? Did we discuss that last week while I was still drunk from the night before? Am I fired?
-Looking for a job as a materials chemist or multivariat
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 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.
All temporary solutions are permanent.
Along the same lines, for software there is only one choice, overall, for software development.
- Cheap
- Fast
- Good
You can pick 2 of the 3, but not all 3. Cheap and fast is not good. Fast and good costs $$$. Good and cheap is never fast. You get the idea. It's just a fact about the software business.
Oh man, if they can sell a $100,000 support contract, they'll never let you do it properly.
I don't know why people just assume that because one implementation didn't work, every variation on that implementation won't work. As it was, however, the Soviet Union did not get rid of money.
All weakness is within you, As is all courage.
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.
if you catch my meaning.
hmmmm no, what do you mean? That was much to subtle.
----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
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
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.
Tao of Programming, 3.2:
"There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, `What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.'"
In order to move software to a well-architected foundation, you need something that works and costs too much to maintain, or, you need large pockets of start-up or reasearch and development cash.
In the first case, you can relatively easily take headcount, hardware, and software expenses for segments of system development and show that over time, the complexity of any given system begins to turn nearly straight up. (Imagine a line graph with a line that goes from left to right for 2 years, then begins to incline slowly for 2 more years, then goes straight upwards from then on). So the justification for re-architecture is that you can move the complexity back down to a managable level, flatlining enhancement and maintenance costs for a few years, as opposed to continuing forever on the hugely expensive track you're currently on.
The latter scenario is much more difficult to implement since no CEO I know likes to risk money on planned development unless there are buyers willing to wait. You may also find (unlikely) investors that feel so strongly about the foundation of the software that they're willing to risk the initial cash-flows.
The best bet is to make every attempt to refactor things and build things with refactoring in mind as you make progress. Try to use a layered architecture....try to abstract as much as you can...leverage any and all talent on your team to accomplish things in a "ready to refactor" manner.
There's no hard answer. It depends on where the cash is coming from, who the customers are, what state any current products are in, etc etc. It also depends what type of team you have. If you have a bunch of hackers, guess what...you're going to be writing quick and dirty code. If you have a team that understands structured development and you have strong development leadership, then you're far more likely to get buy-in for more formal development practices.
It's always a battle and it sometimes comes from above, but there are many coders that would shoot you if you tried to get them to write anything down on paper first.
Personally, I prefer a formal environment that _I'm_ in charge of. This way, I get to set the rules for when things can be hacked or not.
http://chicagodave.wordpress.com
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.
<^>_<(ô ô)>_<^>
I think that you will find that there have been numerous variations on this theme over the ages. I also think that you will have a very difficult time finding EVEN ONE that would be described as successful by any reasonable person and has survived until today.
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.
I kid you not, these things exist. I learned all about them in grad school.
TPS = Transaction Processing System, and TPS reports are a produced from them with many various options, interpretations, and meanings.
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...
Unfortunately, this is very hard. Business moves fast and programming, like any other science, can be very rigid and thusly unforgiving when 1 little thing is 'incorrect'.
Most programmers I know like to take their time and think about stuff. Most biz people I know want the millions and want it yesterday - that's their job. There is very little middle road to walk here since money drives pretty much everything and ultimately that is the commanding force.
Sure, you bnag something out, the contract get's signed and everyone's happy - for that moment. However, when bugs crop up, tensions flare and people start pointing fingers, etc..
The only way I've seen it work - and I haven't seen it much - is to start from the get go and convince the people you work for/with that the project is not something that can be banged out soon. But, this will get a lot of frowns so in addition, you gotta speak the language of biz people. Make project and dollar predictions on why it will be better, in the long run, to do a better job in the beginning. When biz types start seeing dollar explainations, then they can start adjust schedules, contracts, etc.
It's not hard to do, but it does take some dilligence and foresight. Like so many, I too have the urgency to just jump right in to something. But I've seen over time success is within reach when you, unfortunately, manage others expectations. If you cannot do this, then the people writing the checks will always have your balls in a vice.
Office Space, cult classic among cube workers, See also.
"Sic Semper Tyrannosaurus Rex."
I have no real answer, except that I feel your pain. What I'm about to say would probably help, but unless you're strict on the point I'll make, you'll be back to the same frustration.
I would suggest writing a PAPER contract and getting official PAPER signoffs for each phase reached (yes, with their REAL signatures and REAL dates for REAL milestones reached....)
Make THEM follow a process that determines up-front the real, fixed business requirements, with cost estimates for hours worked, processes required by you/them, etc. Don't allow them to verbally request/require anything. Besides, a "strict" contract makes you look more professional. Put all expectations (money, time, documentation reqs., process reqs., business reqs., amendments, scope changes, cost increases, etc.) in writing and spell things out clearly and plainly, so both sides know exactly what to expect.
In other words, make it a legal, binding contract!
Then, under promise and over deliver. Go beyond what the paper contract expects of you whenever you can. This is how you make the customer happy. Happiness == over delivering on expectations; on the other hand, expectations "change without notice" when there is no paper contract....
If that means you come up with a Q&D that delivers early, goes under budget, etc., tell them that you are in prototype/alpha/beta stage and pretty up the product with the remaining time, even if it means redeveloping it The Right Way. If they are content with the Q&D, spend the rest of your time cleaning your code, making cosmetic changes, testing, and documenting everything.
We all know that it really takes 3-4 development cycles to do things The Right Way. And we know that around 70-80% of your actual development time is testing and debugging, if it's a good quality application done The Right Way. However, most business/marketing types look at any IT project as a cost and as a burden. If you can under promise on paper and over deliver your product, you're on you way to creating a Win/Win solution that makes people happy.
Development is an art; it's like the proverbial author of books who has a trash can full of wadded up type written pages before a manuscript gets written -- it may take them 10 tries to write just one page. It's sad that this message never seems to get through to the business decision makers.
They expect magic from those black boxes we'll call computers and expect wizards, whom we shall dub "developers," to perform miracles using black arts and mysterious incantations (a development cycle). In other words, expect them to be utterly clueless about your side of the fence. Use a paper contract to help dispel their myths and to clear up any confusion.
Having clearly defined expectations makes everyone, especially customers, happier. (If they change these expectations, there should be a clause in the contract that addresses extra time and money for alterations.) A contract should right-size everyone's expectations.
Now, I can hear flames from the Extreme Programming/Agile Programming people, telling me that customer expectations will change, but I'd still hold fast to the ideal of spelling out expectations on paper, including what to do in case of scope changes.
I also can hear the cry, "A contract will get me sued." A contract, whether verbal or paper can get you sued, either way. Verbal "contracts," however, change constantly and become hearsay.
(The other extreme is to over analyze. I've seen so many projects get into this quagmire. You know the old proverb that a camel is a horse designed by committee....)
I've learned this from the school of hard knocks. I too have been frustrated and have been burned badly by not having things clearly spelled out ahead of time.
Get a paper contract that makes everybody follow a balanced process.... Of course, we live in a perfect world, customers actually know what they want, world hunger is now solved, yada yada....
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.
Wendy is so not going to call, loser.
autopr0n is like, down and stuff.
From experience, Build something working, Call it a prototype to those who want it 'clean and proper' Call it a trial version to those who want to sell it. Basicly, the proper way is too expensive in the short run and it will push costs up. Just make sure that v2 is made clean and payed for by v1. (either by investors liking the trail, or actually releasing it to the market)
Quick and dirty solution:
$1000 to make
$100000 to support
$1000000 in profit (for getting there first)
or
Proper solution:
$10000 to make
$10000 to support
$10000 in profit ('cause someone else got there first)
The nice thing about "Quick and Dirty" is that it can get you there first... That is a fairly important factor.
In situations where Time to Market is crucial, it's often better to do "Quick and Dirty", then start from scratch and do "Correct and Proper" for version 2
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 small business, where Quick'n'Dirty is literally the difference between Life now, or a slow and lingering Death. But either way, you're still around for a bit longer.
There's mid-sized business, which is (hopefully) either growing too fast to know what it's really doing, or comfortably well-off (established products and/or customers, etc). If it's growing fast, Quick'n'Dirty is again the only way, because otherwise the momentum stops and you risk the whole house of cards crashing down.
If you're a comfortably established mid-sized business, or larger, then you really have to focus on keeping what you've got. Customers will leave if you don't look after them, and products will die if you don't maintain them. The only two uses for Quick'n'Dirty are:
1. QADFIP - The Quick And Dirty Fix-It Program, that overcomes a glaring error, or sudden change in requirements.
2. A competitor falters, and marketing have one chance - THIS WEEK! - to pick up their customers. See number 1.
If you deploy a QADFIP, the PHBs need to understand that it is a QADFIP, and that you willl spend the next week (or so) cleaning it up TO KEEP THE CUSTOMERS it won you.
To use Quick'n'Dirty programming under any other circumstance is self-defeating - and you will find yourself ultimately accountable for your actions, regardless of who told you to do it.
Remember - you did it, not that loser in marketing.
With each breath in, a flower somewhere opens; with each breath out, a flower withers away. In between lies beauty.
"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
-Adam
"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.
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
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.
- Fast
- Good
- Cheap
Pick two.Keep it in mind, and you'll be amazed at how it applies to everything.
One simple rule for its versus it's
You forgot to mention the part about your employer being located in Berlin. Not that I'd mind living in Germany for a few years
What... and give up on your third masters? I'm disappointed in you.
-a
There are 2 extremes of programmers: idiots and idiots. Everyone else falls somewhere in between.
Half the idiots are the ones who absolutely believe that their 5 years of industry experience qualifies them to be sole judge of absolute right and wrong in things such as languages, technology, coding style, etc. These poor souls believe that all engineering should adhere to strict policies regardless of business timeliness. These idiots tend to demand schedule delays in favor of constant pursuit of architectural and stylistic perfection.
The other half of idiots see no value in structure and discipline. These tend to be people who abuse XP and will always do only the bare minimum. They produce spaghetti code and are frequently strange people who have absolutely no regard for best engineering practices whatsoever. These guys always deliver utter crap on time and the working version 2 months before the company goes bankrupt.
Then there are the in betweens - the rest of us. Those of us that can be flexible know when to deliver the fast, spaghetti code to land the customers. We know when to architect things for long term efficiency. And we know that usually, a good engineering team is a steady balance of these two. We know that engineering is a constant cycle of research, plan, code, refactor.
So, to answer the question: if you're in that situation, unless you have faith in the people around you, quit. Chances are, you'll deliver the goods, save the company, only to have some self-proclaimed "god" of programming tear your code to shreds for being sloppy, make a fool of you, and never actually have to deliver under the same conditions.
Face it, you're doomed.
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.
Muchas Gracias, Señor Edward Snowden !
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.
and getting too far into the details of this specific problem, referencing coding techniques etc. The actual problem is common to pretty much any worker when he's asked for a good product as soon as possible - when he knows these two edicts are both impossible to fulfill simultaneously.
Personally I feel the most important thing is to get the superior to 'buy-in' to what you're doing. If time's short and you don't feel the product will be great if done within this limit then tell your boss, explain your reasoning, document what's not going to be perfect and get him to stick his name to it.
This actually helps in two ways, if it does all go wrong you have a very good defense (I told you so), but more likely your boss will get the initial constraints altered e.g. explain the situation to the client.
Occasionally when time is short and the work is urgently required you're going to have to release a buggy mess of code. My personal advice is to get working on a point release of it the moment the original has left your hands. It'll take a while for the code to be implemented and the bugs surface. If the moment the user reports a problem you can produce a lovely working upgrade then they'll be impressed with your customer support and you can sleep at night.
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.
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.
The solution to this is to fix the process, not the people. In this case your "quick and dirty" approach has been shown to work and needs to be integrated with the official processes. Write down the criteria for projects where this process should or should not be used. State the limitations, costs and risks clearly. In particular, it sounds like you have difficulty getting resources to go back and do it right, so put that into the process. Then get your shiny new process approved by the process police and inserted into the official manual.
There are two kinds of organisations that have process manuals and make sure they are followed. One is a mature organisation of CMM level 2 or above. The other is an immature organisation at level -1 or below, in which counterproductive processes are rigidly enforced. The test that distinguishes them is what happens when someone proposes an improvement to the process.
Good luck,
Paul.
You are lost in a twisty maze of little standards, all different.
Just a few question for you Slashdot crowd:
- why computer industry has to cope with such incredible decisions such as choosing between producing something good, or producing something quickly?
- why computer industry has a so special place in our business world that practices that will be judged and punished as criminal (such as releasing a hazardous product, boast inexistent features, etc...) are so common that even Joe User doesn't care anymore?
- finally, shoudln't we IT workers (from code-monkeys to gurus) throw PHBs, bean-counters and marketroids through the 100th floor windows?
Maybe an beginning of the answer to the above question: other arts, craftmanships and industries have been around sometimes for centuries, and people working in this fields inherit the respect due to such ancient arts. But computer industries (both software and hardware) were born in an age dominated by money, where quality comes second to profit, and never had a chance to win the required respect to such critical appliances.
--
Arkan
This was probably said before, but every situation is different. Everything must be looked at, balanced and decided as they come. But the best thing you can do is always keep a "paper" trail of every decision made. By paper I mean email, your notebook, anything written that you can reference later on. And if you have something to say such as a suggestion, the best way to do it is in email. If you made a suggestion verbally during a brainstorming, make sure to follow it up by email. It sounds very impersonal, but it's the only way to show that you're doing your part when the heat starts coming.
And always carry around a notebook. Anytime any verbal agreement is made, or you produce something in a brainstorming section, write it down, with the date.
Deciding where to draw the line between getting it out the door and getting it right is tricky, but whatever you suggest or decide will be written down, so you'll always be on the "I didn't slack, I did my job" side....
Buses stop at a bus station
Trains stop at a train station
On my desk there's a workstation....
I used to believe my PHBs when they told me something was for one use and that it would be discarded afterwards.
I once worked for a games company that asked me to take an existing text-only game, hack a graphic user interface onto the output routines, and produce a more up-to-date version of the same game. I told my bosses that it would work, once. The resulting code would be ready quickly but would be an unmaintainable mess, and unusable in other products. "Fine" they said, "Its just a market test".
Nine months later I'm in hot water because I'm insisting that the Version 1 code for the game is unsuitable for use in Version 2, and needs to be rewritten.
I have, since that time, had so many jobs in which I was required to maintain 'quick-and-dirty' code which ended up being legacy code, that I no longer believe anyone who says something is throwaway. I always try to make the code be portable and maintainable, because all too often, I'm the one who ends up having to port and/or maintain it.
I think the question is wrong. It is not "quick and dirty" versus "correct and proper", with the assumption that "correct" takes longer. Usually a little thought about design can greatly reduce the amount of code required. Less code means less development effort, less documentation, and fewer bugs.
You may need to try several algorithms to prove which one is the best, but this becomes instinctive with experience. Soon you will not need to code several approaches; just list the options, picture the code in your head, and drop the longer ones.
Back in college (1989), my C teacher enjoyed my homework code because it was less than one page while the other students turned in 4 or more pages. A good portion of it was pointers and the ability in C to make one-line "for" loops that moved blocks of memory. I had to comment each line, because they were so cryptic that I would forget what they did before the code was done. But the programs were short, worked, and were maintainable with the comments.
Yesterday at a client, I refactored some code. A few minutes earlier I had copied a function to make it work with a different global list. (The lists hold configuration data, so globals make sense. And the code is loaded for each run, so there is no chance of contaminating other portions of the app.) This was now the third copy of almost identical code. AFTER PROVING THE NEW FUNCTIONALITY WORKED, I made a generic function that took the list as a parameter and replaced the calls. Tested again, then removed the original functions.
- The original code worked. It was not "dirty". But the new code is shorter and more maintainable.
In the last week, we made a major architectural algorithm change to my company's product. The original code split a request into two parts, handled each request separately, then merged the results. This was "dirty" because a hack was needed to make transfer data from one portion of the request to the other during the merge. But it worked for the last 2 years: it allowed us to write the lower level code, and it did not affect the functionality.
- We just added functionality where the hack would interfere. Now the requests must be handled as one. Because all of the lower level functionality existed, we were able to make the change with about 40 lines of code, replacing over 100 lines. There is still code that refers to the hack which will never be triggered because the input will never have the hacked parameters. We will remove the obsolete code AFTER the next release to save the need to retest many of the modules. (We are really close to the next release.)
- This hack was almost "quick and dirty". It was done because at the time it was designed, none of the lower level code was available, and we could not envision how to integrate the two requests, and there was no need for them to be integrated. The hack to merge the data was added when we realized some data from one request was needed by the other, but it was extremely simple to pass the data. We remained aware of the issue, and were ready to "fix" it when some functionality required the integration. Since the separation occurred at a very high level, and everything was planned with awareness that this change would come, the integration was accomplished quickly.
- We spent 2 days planning the change before writing any code. Because of this, the code took about 3 hours to implement. If we had just sat down and started coding, we would still be working on it, and probably have a buggy mess. Another benefit is that the new code is shorter and more maintainable.
Better design always requires less code, which requires less development effort.
I try not to write code the same day the specs are given to me. Tell the PHBs that the code will be need to wait for tomorrow. Your subconcious will work on it while you sleep, and the solution should be better, cleaner, and SHORTER.
I spend my life entertaining my brain.
Frankly you can only spend so long designing a program the first time around. This is especially true if you're building it for a customer as they never really know what they actually want to begin with.
:-}
:-D
So, you slap something together and you show it to them and say, "So is this what you were thinking about?" Usually they'll say, almost, but I want this different, and what about this feature, and why is that button over there...so on and so forth.
Frankly I believe we used to call this prototyping. Now, in the real world it is easy to see that a prototype is a jury-rigged thing that will fall apart if you push it too hard. In the computer-world if the GUI looks polished than the program must obviously be done.
This is probably responsible for more things remaining Q&D than anything else. (Though some blame belongs with us programmers who don't always like doing the cleaning up work.)
Maybe we need the graphical equivalent of duct tape on the prototype's GUI so people realize that it IS in fact a prototype.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
Many other people have posted the same thing, but here is a real world example of when Quick and Dirty solutions are required:
... He was dying, so I had no choice but to run to a hardware store to buy a drill and use the pliers that I fix my car with, of course after sterilizing them," Cesar Venero told Reuters in a telephone interview.
LIMA, Peru (Reuters) - Lacking the proper instruments, a Peruvian doctor at a state hospital in the Andean highlands used a drill and pliers to perform brain surgery on a man who had been injured in a fight, the doctor said on Thursday.
"We have no (neurosurgical) instruments at the hospital.
The patient, Centeno Quispe, 47, had arrived at the hospital in Andahuaylas, 240 miles southeast of Lima, after being hit in the head with a metal object in a street fight, Venero said.
"I drilled holes in his skull in a circle, leaving spaces of 5 millimeters, took out the bone with the pliers and removed the clots that were putting pressure on his brain," he said.
Andahuaylas is one of the poorest regions of Peru, a country in which more than half its 27 million people live below the poverty line.
Venero, who earns $430 a month, said he had used tools from a hardware store on five previous occasions but for less serious operations.
Quispe was making a good recovery in a hospital in Peru's capital, Lima. "
Holland
The basis for your question is your belief that the quick solution will bring in the revenue/land the contract/ whatever.
I think that assumption is wrong and here is why:
Outside of new economy / dotcom era, things really don't move that quickly in the business world. I work for a fortune 300 company and we are lucking to make a decision about anything less than 60 days. I used to do government contracting and that was 1-2 year contracting sales cycle.
Bottom line if your customers are existing/established businesses, then there are rules in place to prevent anyone from spending lots of money quickly. So time is always really on your side. Even when sales and marketing say that something is a done deal, its a go, we starting right now, it will probably be weeks before contracts are signed and checks cut and expenses authorized.
Stop believing the lie that everything has to happen NOW, NOW, NOW.
And ask your self, if the sucess or failure of your company is dependent on feature X being availble right now, why wasn't that identified long before this crucial moment? Whose doing the product development? Who is gathering requirements in advance of customer need? If your customer base is still in the fast and furious mode are they long for this world? If your company doesn't have a long term plan and is just reactionary are they long for this world?
Truth: If it's not one thing, it's another