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.

That said, quick and dirty is always more fun.

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 =)

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.

• Unix v/s ITS (from the paper)
• C v/s Lisp (from the paper)
• Linux v/s Hurd
• Opteron v/s IA64

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

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.

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.

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 ... ?

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!

• Fast
• Good
• Cheap

Keep it in mind, and you'll be amazed at how it applies to everything.