Posted
by
Cliff
on Thursday July 10, 2003 @04:55PM
from the which-way-would-you-go dept.

A not-so Anonymous Coward enters this query: "I keep finding myself on projects where a quick and dirty solution will bring in money for the company, and a correct (ie, properly documented, well engineered, process followed, etc) solution will get us left in the dust. When the Q&D solution succeeds, I'm left trying to explain why it can't be the FINAL solution (to PHBs and Marketroids that were fully informed of the situation prior to any work getting done). Most recently, work I did in record time was used to help bring in several large contracts, and then I found myself in hot water for not having followed process et al. So, to Slashdot: is it better to do the quick thing and greatly increase the chance of $uccess now, or to do the correct thing and avoid pain later (assuming there is money to pay for the pain later)?"

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.

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.

Think about it--why does the Open Source model produce better code [reasoning.com]? 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.

The culture of the Pacific Northwest Indians revolved around ostenatious display of wealth. Just one example out of many. Just because they didn't have money and most didn't have the concept of land as property, doesn't mean they didn't desire to accumulate wealth.

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.

And with layoffs coming every couple of months, I sure as heck don't want to be tech lead on the project that missed its market window because I insisted on perfection. I try to balance risk/reward, taking shortcuts on the less risky parts, negotiating to eliminate unnecessary functionality, and doing whole-hog process on critical system components.

What about my experience, then...You work for a government contractor on a project for the army.You quickly discover that one of your coworkers is putting code in place on production servers that is VERY nasty, buggy, full of gaping security holes, but slightly more often than not, actually does the job that needs to be done.You get with your supervisor to point this out, let them know that security standards are being completely ignored, crash recovery (done by another group) is taking more time than doing it right in the first place.You and the REST of the team get let go, while the quick n' dirty guy gets promoted; the Army has to nearly triple the size of the group doing recovery.Grrrr.I may be blackballed by EDS, but I would never, ever, ever consider working with or by those scum sucking pigs again.

What we need to do is draw a line as to how dirty it can get (analytical skills here).

Analyze where in the market you stand and ask some quick questions1) How much time do you have2) 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.

I can only speak from my experience at my current employer. The company is founded by two CS PhDs, so no PHB trouble. We don't follow any formal process in our development, we don't even comment the code, which really pissed me off in the beginning. However, what we do rather successfully is to make everything as simple as possible.

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

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

UGH... Talk about all the wrong things to do! The idea of fixing problems early is good, but your method of doing it sounds to be out of control.

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

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

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

You're right, there is no definite answer to this question, however there are some ways to create a balance.

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

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

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

Stick to the timeline

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

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

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

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

First, as someone else in this thread stated, the first version of whatever you crank out, no matter how well-thought-out, isn't going to be ideal. Until the product has hit the real world, and real people have used it to perform their work, there will be unidentified inadequacies, design problems, shortcuts needed, etc.

I always approach things from the "Do it right" perspective -- initially. I figure out what seems to be the best approach to resolve the problem. Admittedly, part of "best" does involve budgetary issues - on a shoestring budget, "best" can't include hundreds of thousands (or even tens of thousands!) of dollars' worth of high-end hardware and expensive software, and that's unlikely to change even over the course of years, in most cases.

Once I've decided the "best" solution, I look at how clean I can make a solution that fits into the budgetary constraints I'm working in. Lay the groundwork for versions 2 and 3, as long as it doesn't prevent you from reaching your version 1 goals.

Now, it doesn't necessarily pay to be to lay that groundwork too extravagantly; as noted earlier, at least part of version 2 will be responding to the comments, complaints, and critiques of the users of the system. Unless you have the luxury of spending an extensive amount of time with end users, getting their input on everything from validation, auto fills, and screen layouts to the color schemes to use, there will be requested changes.

Also, remember that you're almost always serving two masters; the end user who sits in front of your creation, and the guy who signs the checks. If you want to finish the project, the check guy has to be happy; if you want to get more work down the road, the end users better be happy.

Ultimately, communication is key. As others have said, document what will and won't get done, and get sign-off on it. When (not if) the client wants to change things, point to the contract that either says that the delivery dates will changes or that changes will be made after everything on the current approved timeline is complete, and that the client will pay when things change.

You're stuck in the middle of everyone using the various aspects of the program (not to mention the people writing those precious checks), so take on the role of middleman fully. If the end users convince you that something is required, discuss it with the check people until they either understand why it's needed or make it clear they don't care why. Do you best to make sure the client understands why you recommend against a particular course of action. Document when they choose to ignore such advice. Then do what they want (barring ethical/moral/legal issues - only you can decide if you're willing to get fired (maybe "blacklisted") over what's going on).

In short, pull as close to "do it right" as you can, and try to make it as easy as possible to come back later and fix the "quick and dirty" parts, if you can. And make sure everyone knows what's what.

It's a Mallrats reference; see the movie if you haven't. Actually, see Clerks first, the Mallrats, then Chasing Amy, then Dogma. If you like all of those, see Jay & Silent Bob Strike Back and An Evening With Kevin Smith.

Since we are on the sex analogy, well the problem is that the young attractive lady, turn out to de a demmanding women recriminating every one of your move, and always asking to sekll yourself as cheap as possible. And if you aren't quick & cheap enough, then , well, there is always the concurrence.

As another poster said there is no easy solution despite all the analogy you can come with. it is a case for case.

"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"

How about correct and quick? If you don't write clear code and document it well then any time you save coding will be eaten debugging. Either way it will take the same amount of time, and if you rush and skimp on the documentation then you'll have unmaintainable code as well.

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.

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

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

Companies aiming for $uccess while compromising the quality of their software will only obtain this success in the very short term... Do what they want now, but look for better pastures while you're doing it, because your company won't be around for long.

Yeah, totally right. Just look at that stupid company Microsoft that put out their first OS, QDOS? Quick and Dirty OS. Talk about a bad business move. Imagine how much richer Bill Gates could be today if he had only taken a few years to write a perfect from the ground up OS that would be easy to support and modify for the future. Something like BeOS maybe. That would be cool.

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.

"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.'"

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.

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.

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

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

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

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.

Any down time should be used to create the circumstances so that a proper procedure solution can be quickly, cleanly applied. For now, though, get the damn sale. If you're around long enough (and anyone still cares), you can fix it later.

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.

In my experience problems like these won't ever end until you prove yourself first by implementing The Right Way at least once. Before that the PHB just thinks you want to play|learn on company dime|extend your contract.

Once you've done it correctly once, they're much more likely to be putty in your hands, because you've gained credibility.

Of course the trick is to get that first success, and, sometimes, to convince them that the thing doesn't break because it was fscking done correctly, not because it's simple. Many times you end up making things look easy when they're really not, and that gives the wrong impression. Sigh.

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.

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.

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.

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!

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

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

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

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

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

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

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

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.

I keep finding myself on projects where a quick and
dirty solution will bring in money for the company, and a correct (ie,
properly documented, well engineered, process followed, etc) solution
will get us left in the dust.

If this is true, then the author of the original post has answered his
own question: The quick-and-dirty solution was the correct
solution. What he had initially labeled as "correct" -- good docs,
adherence to sound processes, and so forth -- according to his
analysis wasn't viable; it would have caused his company to be "left
in the dust."

So he did the right thing.

And yet, he offers this testimony later:

Most recently, work I did in record time was used to
help bring in several large contracts, and then I found myself in hot
water for not having followed process et al.

What went wrong?
I'll tell you what went wrong. The author apparently made the choice
to go quick and dirty by himself. Instead, he should have
forced his managers to make the call: If you want to go that
fast, we'll have to cut corners. Are you willing to accept the
consequences? Then he could have held them to their decision.

If they came back to him later with complaints about quality or his
deviation from internal processes, he would have had a sound rebuttal:
You told me to cut corners, and that's what I did.

But it's not always that simple. Sometimes it is irresponsible to
cut corners, even when your managers direct you to do it. For
example, if you're working in an engineering capacity, you have a
responsibility to the public to protect their safety and well being.
If your boss asks you to cut corners on the software that controls
X-ray dosing in medical imaging equipment, your answer must be,
No.

Nevertheless, even in this case, the right thing to do is force the
managers to make a decision, and hold them to it. I'm sorry, but
I can't cut corners. We both have a responsibility to the public
here, and so we have no choice but to find another way to meet our
timelines. Agreed?

So, to answer the final question:

[I]s it better to do the quick thing and greatly
increase the chance of $uccess now, or to do the correct thing and
avoid pain later... ?

When you get a quick time-to-market deadline, make sure you spend at least a certain amount of time up front on the proper structure and upgrade methodology. The goal is to have a product to ship that is relatively painless to upgrade, or even, if you can swing it, built into the product life cycle (i.e.: software as a service). Then, lay out the guts and the gui, keeping in mind the features and tweaks that will come with the first upgrade.

This is really the SOP (standard operating procedure) for most of the big dogs out there in softwareland. It works pretty good and is generally acceptable to the user community. Think pluggable, modular (sort of like OO for the youngsters in the house, but takes more thought and works better), and non-statically linked.

On the OO comment, there are some good OO tools and languages out there, don't get me wrong. It's just that you have to understand good modular programming to keep from OOing yourself into spegetti code, which is way too common. OO != modular if it's not done right. OO != OO if you don't understand it. The same thing goes for RDMS work. If you don't understand relational theory and the underlying structure of the RDMS in question, you might as well be using text files and awk. (boy was that a rant or what?;^)

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.

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

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.

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.

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 market2) Cost to develop3) Maintenance4) Correctness/reliability5) Performance6) Extendibility/architecture7) 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.

"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 agree. Where I work, we often complain that we don't have time to follow a process, but we usually keep the products rolling out and the customer happy, because we built a continuing improvement cycle into the post shipping date. Rather than normal bug fixes, we work hard to find out what the early adopters need fixed, and what else they used. This might leave some buggy features uncorrected for a longer term, but if the buggy feature is unused while a new feature keeps the customer happy, no one complains.

XP is better than no methodology. But I agree
that it has flaws. The most important of which is that it
does not recognize the need for architectural design.
But if your company currently has no process at all,
you aren't going to be able to get an architectural
process recognized. Officially adopt XP, and try to
do the architectural work "off the books". Even that
is better than "quick and dirty".

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.

Don't let their monopoly status or proprietary anti-unix stance lead you astray. Microsoft does some pretty good coding. They are far from perfect, but in the large they do correct and proper solutions.

For example, DOS. People today laugh at DOS and the problems it caused Windows on i386 machines. Many would point to it as a quick and dirty solution. But those who do fail to understand that DOS (a CPM clone) was a correct an proper solution to a 8086 with 640K RAM, and that they quickly started working on