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.
the point is to get more money with less investment while getting trust from cusmers.
hit the sweet spot.
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!
Nice flowery speach. Unfortunately, correctness and validity outweigh passion in a lot of manager's (and customer's) minds.
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.
IMO, getting contracts and money in sounds awfully good...
Who doesn't like it quick and dirty?
This isn't the only aspect of life where quick and dirty is superior. If you stop to think about it, most things feel better when done quick and dirty. At least dirty, I know I like it dirty anyway.
You know the kind of dirty that you won't get on afternoon tv, passions, etc. Know what I mean? And I'm not talking pay tv in a hotel dirty either, I'm talking real life forbidden in 49 states dirty. Huhu. Yeah, that's it, I knew you dug it.
How small a thought it takes to fill a whole life
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.
Either is fine with your mom... :)
But, ultimately she prefers 'back-door love', if you catch my meaning.
it all depends on your situation, goals, outside forces, etc. why does everyone "ask slashdot" about how they should do things? there is no hidden genie that will make all your problems go away. think about it, then do it.
"a quote" -me
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.
I see you didn't take the red pill...
"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-
Show them that the proof is in the pudding... Give them an explanation of why you did things the Q&D way and how your decision brought in money for the company. If they still complain, then do the Q&D but make it look C&P... Tricky I know, but an "attempt" at C&P justifies your actions, works for me anyway ;)
Business \Busi"ness\, n.;
A scam in which all people involved perceive as beneficial...
I often just want to get up during a meeting walk over to a wall and say "Why aren't you listening to me!!!"
"A synonym is a word you use when you can't spell the word you first thought of." - Burt Bacharach
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."
Just let the marketing guys do the math:
Quick and dirty solution:
$1000 to make
$100000 to support
or
Proper solution:
$10000 to make
$10000 to support
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
Yes! Man, the interface sucks and it takes longer than pencil and paper to get a result, but I am just filled with many warm fuzzies when I discover the sheer passion and drive that went into developing such a substantard product. At least, that's what the developer told me...
One more thing. Usually the product that wasn't built well fails in the end. But it really depends on what market it is, how much demand there is and also who the customer is. The situation is going to be different if this is a product for the consumption of millions of people (ie, a game or whatnot) than if it is a product for a large corporation (large database interface, etc.)
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"
I would do something quick and dirty at first, then try to fix as much as possible if there is time over. Afterwards I'd try to patch what can be saved, maybe run away to somewhere where noone can find me -_- I'd better bring some sort of connection to the internet though, or I'd starve(order pizza to the north pole).
;)
The correct and proper way is the preferred one though, unless you are very time limited you SHOULD(RFC >:)) do it the correct and paper(that's what I read at first) way.
If it's about money and losing money... hmm... maybe looking over the development process to cram some extra %s of properness out of the hackers
if the not-so Anonymous Coward works on the Microsoft HTML rendering engine
"et al" is NOT a substitute of "at all"
__j
...and the oscar goes to Jouster for "Post that brings tears welling in eyes"
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
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...
But not an answer that will appeal to most people.
You make it quick and dirty while on the companys time, but you think it through so that an elegant solution isn't far away.
Then, out of pride in your work and your legacy in general, you make it elegant on your free time. Just be sure to get credit in the headers.
How small a thought it takes to fill a whole life
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.
MONEY!!!
I feel the pain of everyone who is forced into the quick and dirty path. It's somewhat like being forced to join the dark side of the force.
BUT:
When the client needs something done, and the quick and dirty way will deliver, businesses will almost always choose the quick and dirty way.
It is difficult to find a for profit company where profit is not a top priority.
It's one of the things that makes america great. We don't care how bad the product sucks, as long as someone will definitely buy it.
Unless you work for a company with a software quality assurance plan; you're screwed.
If it's a question of losing the customer to another shop that works quick and dirty, do it Q&D.
But get, in "writing" (email), confirmation from the powers that be that you're circumventing procedures in order to get the work done within the timeframe needed.
They can either attempt to explain to the potential customer that it will take longer for a quality product or simply not say a word.
At that point it is their choice. Give them all the options, cover your ass, and get the work done as they want it. If they come back to give you crapola, show them the paper trail of approval for what you've done.
Do what you're told, and document, docoument, document your concerns/admonitions/warnings.
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 =)
JUST GET IT IN WRITING or you are screwed. As a systems engineer I KNOW this pain intimately. No matter HOW they APPEAR to understand the needs and requirments, THEY DON'T. The ONLY thing they UNDERSTAND is $$$'s and personal liability/culpability, ensure that you as a technology implimentor (oooo PC terms abound ) are not the one whose name is on the bottom line... Or of course you can always go Don Quioxte and give your self an ulcer for nothing as well :)
errr....umm...*whooosh* *whoosh* Is this thing on ?
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
"Quick and Dirty" vs. "Correct and Proper"? That is not a good question. That is not a good question at all. Where is e.g. "Quick and Correct"? I am not sure about other people, but this is how I presonally prefer to work. And no, using no strict and no warnings pragmata does not necessarily mean my code is "dirty." I exactly know what I am doing.
Karma: Positive (probably because of superiour intellect)
Tell your bosses that they may chose 2 of the above 3 options for each project. If they ask for all 3, you can either A) find a new job or B) pray.
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."
... by Hunt and Thomas. This book really helps you understand how to achieve balance in your work.
love is just extroverted narcissism
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
Quick and dirty seems to win most often; look at Microsoft!
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.
I used to think there was a choice too, when I was younger. I've since learned that no matter how screwed up you thing the corporate world and the PHB's are, it's much worse than that. I've got stories that make yours seem like a decision between chocolate and strawberry ice cream. They should start teaching this stuff in college rather than engineering idealism! There's no way you can ever win; just retire and work on Open Source where you can do things the way you want to. I so envy Linus' I'll release when it's done position.
Quality is very important, as I'm sure you're aware. Yes, the Q&D hack will be ready soon, and it will work mostly, but what about support? Changes? Documentation? What about when you get 3 new team members and they can't understand what the fuck is going on because everything has comments like: //works..slighty //hackish
etc?
Explain to your boss in terms he can understand - things like ROI, earned value, show him how the planned project costs less to your company in the long run because by catching the bugs in testing you don't have to delay the project a month to fix everything. Let him know that yes, it will take longer to do a proper project, but you get a quality result.
Maybe this will work. But if the whole attitude of the company towards quality is that they don't care, I think that speaks volumes about they are going to treat you on other things.
Yes it can be fun to make quick hacks, but when it comes down to it if all you're doing is coding shit that works enough to get by..well..I wouldn't want to be there when it all starts collapsing.
if you know well enough what you're doing, .. unfortunately,
.. do it how you have .. no matter how much of a rush you .. don't just sit down and bang away .. eventually you become skilled .. but you'll already have it written
.. but a skilled artist can put out a good
Quick & Clean is possible
if you're breaking new ground, that isn't
always an option.
the fact is - you get paid by producing what
your company wants/needs
to do it and try your best to not get fed to
the wolves when the shit hits the fan, which it
invariably does. stick to a good, modular design.
even if the innards of the components are dirty,
design in such a way that you can replace these
q&d parts with clean parts later - design is law!
(hahahar)
are in, it will save you time and effort to have
a design document of some sort (even if its only
in your head)
unless you have a clear framework and path laid
down somehow
enough to Seem like you're just sitting down and
banging away
in your head
clean and proper code is art, and art can't be
rushed
piece more quickly than a fledgling
If you feel the pressure to do something quick and dirty, document it.
Don't be strict about development process, be strict about requirements. If your manager want something done quick and dirty, write up a list of the requirements he's asking for, and a short proposal on how to deliver in multiple phases, phase one being the quick and dirty one. Make sure you include a list of risks with launching after completing phase one instead of waiting until completion of the project, and a list of risks of not following up with the fixes/rewrite/whatever.
Insist on signoff, especially if doing it the quick and dirty way would violate your internal processes.
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
Ten products all based on the same model is much less costly than ten different products.
Don't try to innovate and standardise. If it's the first time you do something, do it quick and dirty and be prepared to throw it away.
Quick and dirty is OK, even excellent, the first time, and it will be garbage-grade material. Quick and dirty is wasteful the second and later times. Conversely, slow & excellent is stupid when you don't know the terrain, and essential once you do.
Lastly, try to ignore the marketroids and listen to the client. (S)he will usually know exactly what they need, but be unable to express themselves.
Ceci n'est pas une signature
Why did I think of this Dilbert comic strip when I read your message?
Evil(dirty) will always win because good(Correct) is dumb.
Insert Witty Remark Here ===>____________________________
I wonder if anyone will have an opinion on this one...
Mine is - What's the difference? Universities have the liberty of thinking about theory and all that jazz. In the rest of the industry, we just want tools to do our jobs. If that tool works but looks like crap on the inside - who cares? Just make the tool the customers want. If it is *too* quick-n-dirty they won't want it. If you take too long to make it nice and elegant - they will have long since lost the need for it. It's just a tool. Make it the best you can in the time you can.
This sort of thing happens every day, every experiment whether you're in academia or commercial industries. Of course, with research, you have to submit to peer-reviewed journals, which adds another aspect to your dollars (quick) and sense (correct) equation.
The trick is usually finding a balance. Do the quick and dirty, show it as proof-of-principle, and then (or concurrently) do it the right way. It's really the only way to please everyone.
We have just been through this over at the place I work. We used to have a great IT manager who managed the place very well. Our environment is one where the PHBs (VP,EVP etc) don't quite understand the value of IT and this is what the previous guy reiterated every time he got a chance. Then he left because he just did not want to continue doing it when the upper management changed. Then we got a new one who keeps delivering whatever the user asks for. Never quite guides them through (no added value) identifying what they want. So everyone is in a reactive mode now. It all depends on the vision of the leaders. If you have bad leaders and good people it won't be soon before those who do the work will start to look bad. Move on to a place that shares your values!
The people who make decisions will always insist on the quick solution, because business today is all about the "slap a label on it and sell it now" approach.
Discussion of this topic beyond the initial suggestion almost always brings out invincible skepticism from everyone else in the discussion, none of whom will believe there is sufficient intelligence present to do the right thing(tm) (because they, naturally, are the smartest people in the world, and they can't figure it out).
Developers who insist are usually the first to be fired, because they are right, mainly, and because they are also failing to be "team players" which means "agree, even when we are wrong." These programmers were exhaustively qualified as the smartest candidates in the history of employment, of course, before they were hired, but they are universally perceived as wrong when it matters.
Taking the time to do things right is risky, but since there are so many risk-averse whining idiots involved, things are almost never done right.
Those are the facts.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
...will understand that quick-and-dirty is sometimes necessary or useful in business, but that correct-and-proper should be the norm; if the latter isn't the norm, then there's something fundamentally wrong in the business.
Keep in mind, though, that there's a vast spectrum between the two, and that correct-and-proper is only one end of it. Cost-benefit should rule the choice, not ideology. The norm should really be something like "sufficiently correct and proper for now and the reasonable future."
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Focus on the business in all aspects of software architecture. Period.
If the business is looking long term, devote the time towards a long term, well architected solution.
OTOH, if the business is looking to get bought up within the next quarter, throw together whatever comes to mind and get it out the door ASAP.
It all comes down to conforming to the business plan of your company (or client). As time goes on, you will earn trust and management won't come barking down your throat every time they perceive something to be off schedule.
Unless you have an altruistic calling, the point of the exercise is to make, increase, and or retain revenue. This is a good thing. If it can be done following process, procedure and good coding practices great. If it requires quick and dirty solutions that is ok too.
How many of us have a dozen undocumented scripts we use for this and that but are really critical to getting the job done?
Like choosing the right tool for the job, Quick and Dirty is sometimes the right tool. Where it hurts is when it is the only tool. Then, you have a man with a hammer and everything looks like a nail.
The company I started working for has some weird issues as well.
First, the product ties its upgrades to its support (paying for support? Then all upgrades including brand new versions are free), which isn't bad, except they COMMIT to FOUR RELEASES A YEAR.
Which for the staff we have, is INSANE. So what happens? Right now the developers are in a tiff with management/sales that we have some SERIOUS data integrity issues throughout the package that NEED to be fixed to avoid some serious nightmares. The package was developed by our current VP (then the only developer) and it's just glue-tape-glue-tape-glue-tape built on a product they only intended to sell to one customer.
We've addressed that if these ever came up, they would be nightmares to deal with (lots of our customers don't back up their stuff well...).
But management/sales feels they have to commit to their insane release schedule and would rather put in new revenue generating features. So their idea is not only to stick to the release schedule of death, but to not do things correct and proper, and would rather see more glue/tape than let us fix some major design deficiencies.
So, more money, or support nightmares from hell? They're choosing short-term money. Agh.
----- -----
Firstly: In the real world, you will almost never have time to do things the correct and proper way. Perhaps some day programming projects won't have unrealistic scheduling demands, but they do today. So, the question is not whether you're going to have to do it the quick and dirty way, but how you can implement a quick and dirty project without shooting yourself in the foot when it's refactoring time. This is left as an exercise for the reader.
Secondly: These managers knew of and approved your plan to do things the quick and dirty way to meet schedule. They then turned around to bark at you for making that choice. Solution: Paper trail. Explain the facts of scheduling life very clearly on paper, and get all important people involved to sign off on any instructions to skip policy-dictated steps. No possible way to complain then, as long as the wording of such documents is crystal clear.
In the absence of a signed document to the contrary, take your pick, but make sure that your written estimates of how long things will take are signed no matter what.
Good luck.
I'm in a team re-engineering our company's website. We had done bleeding edge technology (CSS-2, XHTML, etc) to make maintenance easier. The code was valid all across the board. However, in doing so, we left Netscape 4-era browsers in the dust. A lot of our customer base (we're a small town ISP, not exactly in a high-tech area) still uses NS4, and they were unhappy.
So, in doing the correct and proper, we alienated a sizable percentage of our customer base. We're now working on scaling things down (i.e. quick and dirty code) to make it work in as many client programs as possible.
I know that my experience is not quite what Not-So Anonymous Coward was talking about. My example is more along the lines of large, general product for wide user base versus small, specialized product for small user base. It's bad business to tell a large number of your customers "tough, we're not going to fix it, upgrade your software" when the problem can be fixed with a little quick-and-dirty magic.
More on topic, for an easy way to explain why the quick-and-dirty can't be the final solution, try this:
Print out some of the source code, and say "Ok, you make sense of it." When they can't, continue with "If I leave this project the way it is, and I'm hit by a bus tomorrow, you're screwed. Documentation, etc, is corporate insurance."
"Jesus saves, but everyone else in a 10 foot radius takes full damage from the fireball."
In the marketplace, quick n dirty has spoken loudly. Multics was the right way, and failed. Unix was the quick and dirty successor. Reportedly the filesystem was designed and implemented in a day or so, etc. DOS was originally QDOS (Quick and Dirty Operating System). Somehow over the ages UNIX became some form of the "right way" and MS windows was the quick and dirty hack that overtook the market.
Quality software is expensive. It takes time to design, implement and test. As long as the software can't kill or harm anyone relatively nobody cares. Downtimes are accepted as part of doing business outside IT deptartments, and CIOs have an uphill battle arguing to dedicate capitol to more expensive IT.
I Browse at +4 Flamebait
Open Source Sysadmin
This really comes down to you and your ethics. What you have power with is to evaluate the alternatives and present them to the people who make the decisions. You have to remember to follow these rules when possible.. and make sure you have an e-mail trail giving you specific directions. It ain't pretty.. but when someone comes back on you.. you have the 'evidence' for the 'business' decision and let the chips fall where they may. Yes, you may still get dinged, but if you voice the business process mantra when giving the options and getting a direction.. you cannot be at fault. The problem then becomes the insecurity of a superior to commit to a decision/e-mail trail. Be sure not to just accept verbal go-aheads. Life is not perfect.. but as the saying goes.. CYA (Cover Your A$$)
(1st sig) If this were a snappy sig, you'd be reading it right now. (2nd sig) I'm a karma whore. >Insert FUD here
Well Quick and dirty is good with an eye towards and hooks for the proper way. Its all balance and a good OOP interface can allow you to fill out the implementations later. You should not skimp on the interfaces though.
Refactoring I see is just another word for going back and doing it right the second time. In this situation. And the fancy term sounds like your giving value added, which you are, and you have continued employment....
(CYA = Cover Your Ass.)
You're going to have to do the stuff that pays the bills, obviously. Look around at the economy for proof of that. BUT, that doesn't mean you have to take any guff from the idiots above you. If you tell them what's going to be necessary, put it in writing and get it signed. It's just that simple.
Having said that, I take the 2 phase approach.
First phase is the Q&D.
Second phase is R&P.
And I make damn sure I have sign off and funded P.O.'s for both phases.
Never answer an anonymous letter. - Yogi Berra
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
This has been covered MANY times! There are plenty of "Windows vs. Mac" threads already, we don't need more!
If your bosses/clients want it quick and dirty, and understand the implications (make sure you get it in writing, regardless of how trivial a program it is ), do it that way.
As long as you provide them with their written requirements, they can't blame you, and the pain will teach them to let you do it the right way the first time.
Karma: Food Fight (Mostly affected by Date Plate).
So present and get approval (i.e., budget) for both the initial slapdash work and to build/rebuild it right over a longer period. Make sure you make it clear that you must be allowed to build it correctly, and give a realistic estimate of the resources needed, and don't let your boss(es) forget that they committed to it (they will if you let them).
This also brings into play construction techniques. If you are going to do this, try to design and construct the quick and dirty solution in such a way that you can replace modules one at a time, while retaining functionality. This will prevent the problem of having to replace the whole thing in one fell swoop. Instead, you can phase in the better version and spread the stress of migrating to the new version over a longer period of time, and have better testing. This does mean that your overall "architecture" of modules in the system should be well thought-out, even for the quick solution.
Learn to think in Patterns.
Then, there is less of a distinction. You come closer to "Quick 'n' Proper"
Quick and dirties all the time normally indicates a money starved, ill-managed, non-focused, no goals, unstructured organization. On the other hand, correct and proper normally indicates just the opposite...a well managed and led organization that has it's head screwed on right.
If an organization is giving the proper thought to it's mission and goals, then things will be OK even if you are correct and proper. In fact, they will be much better in the end.
So you have to ask yourself, what kind of organization do you want to be a part of?
We have all been there. Most of us use our best judgement to do what is best based on the current circumstances. The PHB's are always quick to criticize after they take credit for the heroics. Get used to it. You are damned if you do and damned if you don't. Grow a thick skin.
I just did a transcription of EWD 1043, where my man Dykstra said that you should, at some point, expect to be right the first time.
I've seen as many projects fail due to overegineering (=~ "the rigth way") as due to undereginnering (=~ "quick and dirty").
The agile guys take the famous three virtues of Laziness, Hubris, and Impatience and expand on them slightly. There are things that look like they're easier but are not, due to the pain they create (e.g. cut and paste programming). These are called "false laziness" because, you know, they don't make things easier.
Just like the difference between a brilliant hack and an awful kludge is not how, well, hacky it is, but in how miserable it makes your life later.
I think the difference between Quick and Dirty and Doing it Right is not in the docs and all the bullshit that TQM or the Rational process or whatever the current monolithic process your following demands. The difference is in, on one hand, robbing-peter-to-pay-paul short sightedness with a terrible cruft, and in analysis-paralysis on the other hand... hitting the sweet spot between the two is the key, Grasshopper.
Yeah... I'm placed in this position (which I'd call on my back) all too often. Marketing departments and people in charge of financial decisions don't know or CARE to know about "proper coding techniques"; all they care about is getting their product or promotion or whatever out the door with a shiney bow on it so they can show it off to their boss. Knowing that they won't bite if I tell them I can hack together something in x hours I ALWAYS pad my estimates. If the customer pushes I force them to sign-off on the project and I fully disclose all risks associated with the accelerated pace. I tell them that the code won't be as extensible and will probably cost more to maintain... I also make sure they know that I cannot ensure thats its secure. This normally scares them into compliance... their jobs all of a sudden seem more important than the kudos they were expecting for getting the product pushed fater.
Why is this somehow only related to software development. People are forced to make this decision all the time in almost all facets of their lives. We have limited resources and infinite desires. Should you blow everything you have on that Lexus (good reliable car, lots of features, etc) or get a Corolla (still good and reliable, not as many features, etc). Just depends on what's important to you at the time you make the decision. There is no "right" answer.
If you are going to lose a make or break deal if you don't get it done next week, then you do what it takes to get it done next week, whatever that is. If you need to get it done next week because some idiot manager put it there on the schedule "just because", then you have a lot more leeway in deciding to push the date to achieve something "better".
A rather silly question really. You do the best you can do given the resources you have to do it.
Do it right mate. My experience taught me that doing a job the quick and dirty way can make you loose much more than just your time. I work for a guy that made some really nasty decisions during the design process of our program, and now he's blaming me for needing a lot of time to fix the problems we have. A program with a weak structure, a bad design, or general flaws, can give you a really lot of work when it comes to having a clean and working product, or even when it comes to expanding and improving it.
Just my 2 cents,
Diego Rey
diegoT
I find, that there is a gray spot in this affaire. In my current job Im having to do quick and dirty. But I try to leave all the doorways to make it propper in the end. I use a lot of tools to try to get it as propper as it can be in time. Its no use doing something that when is done will be out of date as its the same doing something that will be a quick shot and will die afterwards. So at least what I try to do is get things going as clean as it is possible in the amount of time I got, and try to leave the interfaces for the "propper stuff" done so I can ammend my mistakes later. Surely you have to get the people on top of you that you are not doing clean and propper and that they are accepting it. But beware of a promise to getting it done 100% afterwards, its rarely possible and seldom likely.
If one takes the time to write up a nice well written comment, one has missed the window of modding because not many modders read past a certain point and stop modding. However, if you quickly write up something out of your ass, it will get a score of 5 for being flamebait.
Here it comes, let's hear everyone chime in "I've never been paid to write a single line of code but somehow I consider myself an authority on the subject, and you're an idiot if you don't write 100% correct, well-documented, readable, fully-tested, on-time, and on-spec code."
Folks, this is the real world. Listen carefully: It never works out that way.
... 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
Sure, the users will be fucked in the end, but you'll have a lot of money. With that money, buy a convertible. You may cry over the fate of the hapless users, so drive real fast with the top down, and the wind will dry your tears.
Consensual sex is boring.
I could never get the hang of Thursdays...
You'll either be branded as too slow or too sloppy.
I would wonder about the future of such a company and if it would be in your best interests to look for a smaller, leaner company that could appreciate your talents better.
Though given the state of the global economy at the moment, it might be wiser to just suck it down for now.
Be sure to keep that resume updated, you never know what opportunities might arise.
Are you going to maintain the application? How much is it going to cost to refactor it for the next version? How much is it going to cost to NOT refactor it for the next version?
If you are not going to maintain the application, then quick & dirty is fine, as long as it works. Well, not fine - gross and icky, but no real long-term consequences, and a lot of short term gain.
If you are going to maintain the code, then you must consider how much it is going to cost to build the "next" version. If you are going to have to refactor the code to make a new version work, then how much is it going to cost? Is it more than the cost of doing it "right" in the first place? Believe it or not, the answer is often "no" - it'll be cheaper to refactor later. The only problem with this is that often the time needed to refactor isn't available for the next version, and so that needs to be taken into consideration.
Anyway, long story short, these are only a few of the considerations here. It's a balancing act, and you need to fully understand the situation before deciding. This doesn't require every detail, but it does require a lot of good experience on both sides.
Good luck!
If you do it Q&D, you get yelled at for not following process. If you try to follow process, you'll be late and will be fired. If you tell them you can do it on time but will have to not follow process, they'll yell at you for not being a team player. If you insist they give you a written permission to not follow process so as to get it done on time, they won't give it to you and might fire you right then.
It's your job to ignore process, get the stuff done Q&D, and then get yelled at and possibly fired for accomplishing your goal. Yes, you are living in a Kafka novel.
There are only two ways out. First, you can quit IT and become a plumber or something. Second, you can kill the PHBs and take over the company in a bloody coup. Or just sit there and get yelled at for doing your job.
Central to the problem is the fact that the majority of management decisions are driven by dollars, which are the easiest way to keep score. It's very difficult to put customer satisfaction on a P&L, while an increase in sales from a Q&D solution is easily visible. It's tempting to favour the decision which produces the most easily measured result. The difference between Q&D and C&P is the balance between more cash now with the risk of increased expense vs more expense now with the probability of lower but sustained cash to follow. As many posters have said, each business makes the decision differently, according to corporate style, immediate cash-flow needs, available talent and so forth.
The future is here. It's just not evenly distributed yet. -- William Gibson
- 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'
Someone asked me what I meant by "amortize" in my thoughts on Balancing the Swinging the Seesaw. Since I'm fond of metaphors, I dragged yet another one (home mortgages) into play.
Amortize: "To write off an expenditure for (office equipment, for example) by prorating over a certain period."
When I think about an application, there's a certain expenditure one must make with respect to design. I can do it quick and cheap now and incur most of the cost later when I'm confronted with issues of scalability, interop, and extensibility. Or I can spend a time at the start by modeling and designing for flexibility and extensibility, and consequently avoid compound interest in the future. Think of purchasing an old fixer-upper home: you can select from a couple of properties on the market. First, you want something with the a sound footing and an inexpensive price. Also, you'll probably need a mortgage. The smaller the down payment, the larger the total cost. So ideally, you want your down payment to be as large a portion of the total price as possible. But, your initial cash reserve is limited, so you commit to your down payment and then you can at least move in and start fixing the house and increasing its value. Same thing with applications! In the end you want to move in and improve where most needed, but you also want something with a sound architectural footing. That's a balancing act, though sometimes there's design principles and technologies that lessen (win/win) immediate and future costs. RDF has a great architectural footing those who don't like it are doomed to reinvent it poorly but an immediate/localized cost of comprehension. For example, in RSS 1.0 the order semantic of RDF sequences imposes a cost without much benefit. It's a sequence, but you don't know what sort of sequence: a mandatory RDF artifact for an optional feature doesn't make much sense to me.
Plus, in the great marketplace of ideas, no single design/technology is guaranteed to succeed. Spending too much time on any single technology at the start might be an unwise investment. (Torvalds' theory on design and project management is useful reading on this note.)
Comment removed based on user account deletion
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
If you are getting market with Q&D solutions in the manner you are talking about, then the real hit is probably in quality. The way you justify doing things a better way is to reduce support costs.
One thing that might help is a good QA department. Assuming you have one, correct and proper is actually faster than Quick and Dirty. If you do not have a good QA department, or they do not have the power to stop a release from going out the door, then your Q&D solutions get out the door and cause havoc. Ideally that should drive up support costs.
Look at the bigger (business) picture.
Do it correctly and quickly. Slashdot will still be here when you are finished.
It is 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).
And being quick does not necessarily mean being sloppy. The important thing is to try to organize the tasks that you have to do and do some simple documentation. Simple as in a few pages to help you and everyone else to understand what you're doing. If you don't have the time to write a couple of pages it's not quick & dirty solution it's a cheap one and you don't need to bother.
Working as a contractor I have to meet deadlines like you but I always notify my clients when they ask for the impossible, or rather very difficult for the time schedule given. Of course most of the time they pay accordingly... Doing the same stuff in 10 days instead of 30 does not mean they pay less, rather the opposite! :-)
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.
When i would get blow-back for my projects i would simply counter with a bunch of highly technical gibberish. this accomplished two things
1) it was engineered to make any response make the responder seem like a total moron.
2) it would make the listeners realize that they were so useless and incompetent that to challenge me would only make them look bad.
its an effective use of revers peter principal.
Really - quick and dirty is acceptable for things with a short lifetime. If it's something more lasting it's important to do it well. Ideally - you should develop a process that allows you to develop things rapidly - but correctly. Code these days can be more or less self documenting if you use the right tools. As far as testing goes - it's up to the developers to test their code before incorporating it. If you develop/follow standard patters then "quick and dirty" can be "quick and good".
I think it would be far better to work for a company who puts a premium on process, quality, and correctness. These type of companies tend to be in niche markets, I think, but many are very-successful within those markets. A defense electronics company called E-systems comes to mind (because my dad worked there :-) ). Of course, I also think that the economic reality for most companies is that you have to meet somewhere in the middle to keep your customers happy.
Don't become a regular here, you will become retarded. -- Yoda the Retard
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.
And the answer depends on the needs of the company. If the company needs cash quickly and needs you to do a bunch of other things, and won't suffer too much embarassment at somewhat-buggy and unsustainable coade, then Q&D. If the company has cash and wants to develop long-term relationships with customers who are willing to wait for code they intend to build on, then C&P. Anything in between is a balance.
One thing you can do is talk to your bosses and ask them directly which method would help the company better. Or which method would help their careers better, helping your career, etc...
The point is that you have to decide what the variables are and solve for them.
You need to balance the two. Give the PHBs (especially the ones in sales and marketing) some candy once in a while by getting something done in a hurry, and they'll be your friends. But try to do things properly whenever possible, because this will build you a reputation for reliable code, and prevent your job from deteriorating into debugging hell.
Don't be surprised by your situation. At the present time, no one outside of governments and very large, very established corporations seems to be willing to pay the cost of developing reliable, and properly engineered code. I also think we need better and more time-efficient tools and methods--the current "best practices" mostly just throw paperwork at the problem without solving anything.
After explaining the difference, ask whoever can make that determination to make the decision. Then when questions are asked later as to why your wasting time doing something that was already done, point to the exec and have him explain HIS/HER decision.
I'm actually fairly shocked that the geek who wrote this query didn't think of it. Remember kids, when it comes to work always CYA.
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.
Is make a system that does part of what the client might think is hard but isn't, or use an old product that could be adapted to what they'd want. We then negotiate what specs they want, and figure out what's required to move our codebase to the specifications they desire.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
Read some of the famous papers by Richard Gabriel on why "Worse Is Better". This isn't really an answer to your problems, but it may help explain why things are the way they are.
Worse Is Better
Worse Is Better[2]
People in the LISP world often refer to this. Of course Worse Is Better hasn't seem to help FORTH at all, it's the most "worse" solution of them all. (I'm not trolling, I really am a serious FORTH fan. But FORTH is elegent because of it's simplicity in one's ability to write a compiler for it, not because it's easy/easier to use)
“Common sense is not so common.” — Voltaire
ode to teh anal retentive personalities. Anyone who has had a one and one with his VP, will realize the guy doesn't give a flying f*** about dotting your "I"s and crossing your "T"s. Every project has a budget, and your job as a project manager is to complete this project on time and within budget. I program but my profession is a Job Captain in an architecture firm. I'm good at what I do because I dont waste time arguing ethics. I figure out what the best job I can do with the time frame I have then I do it. If I feel that the time frame or budget is unreasonable I explain this. However there will always be someone else who will take the project and make it work. So the moral of the story
If memory serves, wasn't quick and dirty the kind of solution DOS started out as? I suppose that's food for thought. I guess if it's a solution to an immediate problem, quick and dirty is not always the best option, it just turns out to be the only option. When you have the time and resources, proper is a better way to go. But it's all circumstantial.
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.
You did not attempt to improve the product, you attempted to reshape it your own image after being told not to do so.
Further, you forgot to mention that you were already on a PIP (performance improvement plan) when you were fired and that I as your manager (along with other managers not even in our department) had fielded no fewer than 5 complaints from your peers regarding your being unreasonable and/or hard to work with during projects.
Scheduling a meeting including you was a virtual guarantee that said meeting would run twice as long and that we would cover half as much agenda. You were king of neat-o ideas but a jester when it came to follow-through, except when, as you say, you decided to overhaul the code base when we were on vacation. In any case, I'm not sure why you're complaining. My understanding is you're doing pretty well right now ;-)
The implication is that correct and proper is slow. This is certainly not true. Software that is planned out ahead of time and is built following decent practices completely avoids the late-in-project crawl that hurried projects suffer from. It avoids the integration nightmare, the endless debugging fiascos, and although it takes a bit more time up front, ends up in a product that is not only solid, but on-time.
Rapid Development, by Steve McConnell has a lot to say on this topic. One of his more striking anecdotes regards a programming competition where one team set out to follow a strong process approach. They were far ahead during the first checkpoint, but accidentally erased all their work because they hadn't used source control. They came back the next year (with source control), and won.
Organization will win out every time, regardless of deadline. Do it right the first time and you'll have your quick, with quality thrown in for free.
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.
You should always think the problem through before starting, then you can implement the Q&D solution in a way that lets you grow it into the CORRECT solution later on.
I think this happens to everyone that codes for a product oriented software company, the best you can do is to make sure that what you create can be expanded with minimal loss of code.
The sales guys never understand, they always think that because a Q&D solution works now as a demo that it is finished and can be rolled out to 100k users.
Personally, as long as I don't get woken up at night when the code breaks, I don't mind coding Q&D. As soon as its me that takes the heat for a failure, then its my way of the highway.
Too bad slashdot doesn't have an editor to fix that kind of stuff.
Do you even lift?
These aren't the 'roids you're looking for.
i think it depends on the situation. the company i currently works for insists on unit tests and loads of documentation for even the simplest of enhancements. no consideration goes into whether this change will increase revenue or what the impact of the change failing would be. as a result we have ended up with systems looking like products of a communist state! previously companies i have worked for have been willing to let developers advise on what they think the best approach would be so there would be a mix of top quality on areas that make revenue, and those that dont - a much more sane approach, and these are the companies i have worked for that still exist
The amount of money your program makes will be inversely proportional to the life/quality of the program (don't pack too many features, or too much robustness (aka bullet-proofness) into the first release!).
I am a firm believer of using tools in the way that they are useful, or not using them as I see fit. A screwdriver makes a fine hammer for a nail or two.
We are a small software team inside a larger firm. We have three applications running. Two were done the quick'n dirty way. The third (that I was involved in) was done relatively properly. What I observe is that all three applications have their pros and cons. I could easily argue for and against proper development cycles based on them.
As the applications mature I see that they grow towards eachother in lifecylce. The quick'n dirty ones get stricter and stricter (and longer) release processes with each new release. The properly done one gets more and more corners cut and went from a two-week release process down to four days without skipping steps in the process.
I believe that every developer should be fully aware of the peoper development cycle and then have the freedom to decide to ignore each and every part of it. That works best because you are aware of the risks you are conciously deciding to run.
Recently I became involved in a quick'n dirty project. However, just yesterday I came to the concusion that we have been working too quickly and too dirtily. Knowing the proper cycle allows me to not only point out the error of our ways, but offer a solution as well in the form of a small chunk of the proper release cycle.
In your situation your job is not to fight the quick'n dirty way. You cannot argue the case, because it is too weak to be extended to each and every application you work on. Dirty hacks have their merits and may be perfecty acceptable in some cases. Just be on the lookout for problems that are easily solved by introducing little bits and pieces from the peoper release cycle.
Instead of the whiny kid who is always I-told-you-so--ing you can be the hero who saves the day by offering a simple, proven solution to an acute problem.
"Quick n Dirty Operating System"
IMHO... in the real world you have to sacrifice good engineering methods to get your product to market quickly. I'm sure there are markets that prefer quality engineering over early delivery but in most software markets there is a lot of competition out there. If you can't get your product/new release out before your competitors your customers will jump ship and it doesn't matter how good your software is if no-one buys it.
So to some extent you'll have to take a Quick and Dirty approach. Now this isn't really an either/or proposition. Its a spectrum from using full engineering methodologies at one extreme to a complete hack job (in the worst sense) at the other. You need to balance market priorities with longer-term engineering requirements. But in the end its the companies that respond to their customer's needs - including "I need this yesterday" - that succeed.
Again, if no one buys your software because you don't respond to your customers, it isn't worth anything.
Sailing over the event horizon
what does TPS stand for?
Perhaps there should be a disclaimer in the program stating "this is a quick and dirty solution to a problem, and should not be viewed as a final product" or something similar.
However, it's up to you to then make time and rewrite or improve the program to make it 'correct and proper'. Either that, or shelve it altogether.
So, your marketing guy promises the moon, you are asked to deliver the sun and you have the time to go get a rock somewhere. You end up supporting a windows-like software. If you are lucky enough, you then get assigned to make version 2.0 that will be done properly while somebody else deals with the nightmare of 1.0. So, quick and dirty, to get the market share (if you have first mover advantage). Properly done, keep it for long time. By the way, quick and dirty means many sleepless week-end of work, because the delivery is invariably in monday (or tuesday if it is memorial day or whatsoever). If you do not have the first mover advantage, probably properly done will be better for everybody.
What a can of worms you've just opened...
Get something now so that you have some success, some revenue, and some shot at being around for version 2.
Sure, overall it's slower to do something quick and dirty then go back and revise. But, the difference is that someone else is paying you while you revise, and marketing has something to work with, and sales has something to sell; rather than having all of the time funded by your own investors and marketing/sales left with nothing to work with.
There are many parallels; note that successful businesses (barring the recent few high-profile 'first movers') started out as small shops that worked on getting income, then getting something right, then expanding. You have to still be around next month, and next year.
is competition good, or is duplication of effort bad?
Of course this doesn't work for eveything... but why not do both? Some things I've done the Q&D way to get the job done and then document everything later (taking quickie notes at the time helps drastically) because they need a solution NOW then I doc when the smoke clears. Now I realize sometimes it required two implementations because the Q&D solution may be totally different then the long-term correct one. Do the long term correct one later (with all the doc if needed). Then you look like you da' man and yet all the big heads are happy later. You can even chalk up the second itteration as a/some enhancment! ;)
The best solution, IMO, is to do it quick and dirty, sacrificing all your design principles *except* for modularity. That way the dirtiness is contained, and you can clean it up later; plus, the correct and proper solution won't take as long as it would normally because of what you learned from doing the dirty version (in the same way that it helps to do a rapid prototype). Then, when doing maintenance, your approach to adding any feature and to fixing any bug should be to refactor. And I cannot overemphasize the importance of refactoring at every opportunity after you've written a dirty program.
If the only way to get the business is to be the fastest on the block then there won't be any business to jump on if you're not that fast (I'm assuming that this is custom software you were asking about).
If each system is a one off, then the only hope of doing quality is that you can charge the customer enough to do a 2nd release for them.
If on the other hand each system falls within a particular domain and type of system then you'd should hope to move to a situation where you have boilerplate requirements, specs, and project plans that can be filled out to suit. Don't forget to include proper costing otherwise you may have grabbed a job quick that's going to cost the company money.
If you think about it, the number of sales, margins and company reputation are the only legitimate interests of the Marketroids in the development and sales process. You don't want to ignore those interests since your salary depends on the company making money from your efforts.
So, if you really have to be quicker than the process allows, then it's a management problem. Should QA have different standards for release? Should the required project documents be less comprehensive? Are we forced by the market to kick out junk to get the business knowing that we'll get enough money and time to fix it before the customer relationship is poisoned? Does the market require that we ship junk because everybody else is underbidding the deals and the customers aren't smart enough to know they're getting junk and won't pay for anything else?
If you have no hope of getting the CEO, general manager, or Engineering VP who you work under to fix the fingerpointing then you need to make friends with the salespeople or find some other constituency within the company that will keep you out of the soup when you continue to do what you have to keep the job. If this is the case maybe you should consider a new job.
If you keep in mind the right way to do thing, the quick way will get less dirty. After you do it for years and years you'll eventually know how to get things done quickly and keep them maintainable. But in real life you can never do what you consider the "correct and proper" way to do things. You'll take so much time and waste so much money that you'll never recover it.
This only refers to code though. Make sure you do not skimp on planning and documentation. If you don't know for sure exactly what you are building before you build it, it isn't likely you'll do it right. Document it before you start and get the people requesting it to sign off before you start.
If C'n'P is costing business, then that means you're solving problems you don't really have. Customers don't need 100% perfect stability, nor 100% complete docs, and the programmers don't need 100% perfect dev docs. So you need to overhaul the C'n'P to provide what you need (good framework) while skipping the parts you don't (coverage testing.)
Not that this wasn't entirely predictable.
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
To some degree, it's the old instant gratification versus delayed gratification. You can have one dollar now, or you can have two dollars later. If you take the dollar now, you can put it to work elsewhere. If your extended project will net you two dollars sooner than investing the one dollar would, then from an abstract perspective, it's a worthwhile investment.
However, you must first be able to survive long enough to collect your two dollars, so if it's a matter of "publish or perish", you'd better publish and then clean up the mess afterward.
Additionally, a company has many competing needs for money. If you're not in a publish or perish situation, and if you can show that using the money on your project will result in more profitability than using it on other projects, then in theory, you will get funded.
Real politics, of course, often don't work this way, but the theory sounds good.
Ultimately, process and engineering are only important, to a company, from a profit perspective. A high-quality process will generally result in a high-quality product, but not all companies care about quality. Process purely for the sake of process is wasted money.
Process to meet business objectives may or may not be wasteful, depending on other investment opportunities.
Q&D works great for certain things. If you're bidding on a contract that requires the ability to do 3d visualization and you code up something that can pass to allow you to bid... fine. When you get the contract, you can hire people to do it right or take the time to fix it.
However, if you have to stand in front of a congressional inquiry to explain why you cheated, you will be sorry.
Bottom line is, quick and dirty might not be the "right" way to do something, but has practical uses. "Not right" does not always mean wrong. Q&D should never be used when it's actually the "wrong" thing to do. Do not compromise yours or company ethics... it'll just disappoint your customer in the long run, and if you or your company depends on reputation it could hurt. Bad.
In practice the most common thing I've seen is throw together whatever you have and take it to market, then clean up code afterwards (insert obligatory snide comments about Microsoft here).
if you do it "clean n proper", your company doesn't make the ca4h to survive until next month, year,...
if you do it quick n dirty, you company gets the cash, but will have to spend it on legal problems and (angry) customer support in a month, year,...
so you lose either way.
you should really think about changing your job, pal.
Here's what you do,
You get a quick and dirty version, and release that ASAP. Name that one, "Client/Home"
Then spend the extra 6 weeks to a year developing something Correct and proper, sell that for twice as much and name it the "Server/Professional Version"
Error 407 - No creative sig found
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.
I really do cause I find myself having the same problem. My employer gives me a list of programming assignments that need to be finished and how long each should take. Over half the time the estimated time is way to low to lay a solid code foundation and I find myself writing fast and sloppy code just to be talked down about it later. It's pretty frustrating ... but if I could have more than 15 minutes to write a PHPNuke-like portal with dynamic text-to-link parsing, theme support, and ARTC system I think I could do better. (Thats just an example).
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.'"
It's not that easy. It's one, a case-by-case situation and two, not so much a question of necessarily doing either, but rather level-setting expectations for your business and the client.
You have to look at each problem/project/opportunity as a chance to do the following:
-Make or lose money
-win or lose respect
-gain or lose political power (this is situational and more to do with you and your team than your company as a whole)
How you deliver a solution is dependent on what of those three things you're going to focus on. The unsophisticated answer is to say that "making money" is the most important - but remember that winning respect from a client or business unit can make your team far more money over the long run sometimes. The guidance as to what you will be focusing on will often come from management/sales, as power tends to be concentrated in their hands.
The two options you speak are Quick & Dirty and Long & Comprehensive. The most important rule is: Once you deliver the Quick and Dirty Solution it is THE solution. You will never be allowed to go back and fix it unless it is hideously broken, in which case you are in trouble anyway.
So, you have to look at the amount of money you expect to earn from this client/LoB, both short-term and long-term, your current and desired respect level from same, and the amount of political pull you have from accompanying lines of business. If you're under a lot of pressure from management to deliver a Q&D solution, with enough political power and respect, you may be able to pull out a better solution.
Cover your butt. Emails, phrased in a friendly way, just mentioning potential problems, can go a long way to helping smooth things over when things go to hell. Read about managing people.
Now, the more overarching answer is that the quick and dirty solution is almost never the real solution, unless your idea of quick and dirty differs vastly from mine. It's just not the right way to do business, and will inevitably end up costing you and your customer more money in the long-term, and heaven help you if your customer figures it out.
I work for a company that's building a product, and while we're under deadlines just like everyone else, we simply draw a line in the sand about what features won't be implemented rather than half-assing the ones we do. And just like everything else, its a tug of war between the people building it and the people selling it.
The upshot of all this is that you have to manage the expectations of those that are in control. You have to say what will and won't be implemented, what corners you're cutting, and what the possible implications of those things are. It becomes far more about managing and dealing with people than building technology. I bet in your organization there are managers that somehow consistently manage to get their way - watch what they do, whether its simply presenting problems a certain way or they play golf with the boss - it could be anything. Learn from watching them how to manage the people that create barriers to your building a proper solution.
Thanks,
Matt
--
http://www.gridapp.com
me@mzi.to
More projects/project managers are being measured on two things: on time & on budget. 'Quick' helps them meet those targets. All that managers are concerned with is that the thing works when the client sees it, with little concern for futuure usability of it or if the code is well done/elegant. Most probably wouldn't be able to judge code in that capacity anyway.
They do this all the time, and look at the crap they put out.
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
We're waiting to celebrate this victory. A colleague is adding 1 column to a table and it's proving to be an all day task, possibly running into next week. This is the cost of quick and dirty development.
A feeling of having made the same mistake before: Deja Foobar
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.
<^>_<(ô ô)>_<^>
This paradox is mirrored in this ancient literature - www.dilbert.com
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.
If you want loyal customers. That is customers that recognize your brand being synomous with quality, then you must do things right. Quick and Dirty is short sighted and fine if thats the companies business model. But be preprepared in the long run to lose market share when a competitor does things right and your product fails. Remember quality is what creates loyalty, and loyalty means repeat business and new sales by word of mouth. Quick and Dirty is why America lost market share to the Japan in automobiles. Short Sightedness will only get you results in the short term.
... because there's always a tradeshow just around the corner.
"Derp de derp."
The people you currently work for have expectations that don't align with your vision of what you want to do. You can find a different environment that has expectations more to your liking, but it will take more effort.
Apparently you have particularly high-minded ideas of the kind of systems you want to put your effort into. You want to make quality, enduring products that are elegantly designed and well tested. Find an employer that has those expectations (for real, not just lip service) and try to get a position with them.
Perhaps you need to look at aerospace and build high quality, well tested embedded systems. Maybe you need to consider doing "research" development in academia. Maybe you should work for yourself and see if you high-minded vision of how things are supposed to be done can actually earn you a living.
My point is that you're trying to change the behavior of your employer, when I think what you need to change is your employer. If that's not an option because you haven't built the necessary credibility in your career to interest such an employer, consider this; early UNIX (itself crap, but less crappy that what came before,) was put to work grinding out documents. It's creators are now off building elegance into their various Plan 9's. All the years they spent porting MULTICS crap to UNIX and writing printer drivers to print deadtree legal stuff eventually earned them them opportunity to do the sort of work you have in mind. The operative word there is "earned."
Maw! Fire up the karma burner!
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.
The QA department sees time lost and money spent on engineers to support bugs reported.
The Engineering VP sees additional head count to maintain or rewrite the code at some point in the future.
The VP of Sales see his staff fighting bad press. i.e. lost sales.
Make sure these same managers know what marketing is doing. In a well run company, there are a few, the marketing guys will be stopped in their tracks from pulling this type of shit.
If you work for the average short sighted company, your screwed. I usually get the hell out as soon as I can. Although these days with the lousy job market, it might mean you have to smile and deal with a lot of shit for 6 months.
Good Luck.
or do you mean M$?
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...
When there is money, there is no pain. The PHB you so despise get it. Why don't you?
I find myself in the very same situation quite often. Worse is that I know the Q&D solution WILL have consequences, perhaps in a few years when I'm gone or on another project but the product needs changing.
The correct solution for this dilemma is NOT black and white. You CAN BE FIRED if your boss isn't happy with the rate at work gets done (even if it's good, high quality work). I am not so idealistic that I believe doing good high quality work should come at the expense of a job, at least on the receiving end of a paycheck. Everyone must compromise to some degree, but in general I have seen choices made based in the following ways.
If what do you want to do with your career? If you want to be an engineer, than your reputation with your peers and even with vendors and customers is critically important. You MUST do a good quality job. I'm not saying you should ignore deadlines and requirements, but be thorough and precise. It is your reputation and your most valuable asset, do not screw it up! Be professional.
If your aspiration is management, then clearly you must be results focused. That is what your boss will hold you responsible for, the results are what you will have on your resume (and believe me, you will be switching jobs every 3-5 years, good manager or no). You will be evaluated based upon how fast you do something, using how much money with how many people and what immediate results happened. Moving up inside a single corporation is nearly impossible, it may be a decade before a position turns over, so you rarely will be around when a short term decision goes bad (and not all short term decisions ARE bad, sometimes they're the right thing), at least not if you are aiming high. You're looking for fast results and a way to climb to the next rung, it's hard.
Also remember as an engineer (esp in small companies) you are going to be bought and sold with the product. If the product sux or has no lifetime, then you are shooting yourself in the foot for what? To look good to suits who view you as cattle?
Quick -n- Dirty in corporate is NOT done. Sure, you can make a quick buck, let's say 90% of the time.
... that certainly didn't save me any money, did it? Also -- 10% of the time that we wouldn't save money ... it usually ends up costing us BIG TIME. Labor dollar mistakes can eat a company alive -- and certainly eat away at any savings from other projects.
... we move it) -- trying to cut corners and do things quick/easy way could very well get yourself or somebody around you KILLED. Ever see 20,000 pounds come crashing down from 3 stories? It's ugly...
But when I see employees having to RE-DO their work
In the field -- as we are a rigging and erecting type company (if it's big
You get both Quick and Dirty _and_ Correct and Proper. It looks like both simultaneously!
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
You're a software engineer.
Here's how it's always worked and always will work.
You do a project.
If it goes well and makes money your PHB takes the credit because he managed it, but any problems with it are your fault because you coded it. The PHB gets a promotion and raise, you get 10 hours more work a week.
If it doesn't make money it was *your* "overdesigned" project and it's your fault. The PHB pays no penalty and you get fired. Then he gets a promotion and a raise for having fired you.
It isn't pretty, but that's the way it is.
So how should you code? The way that covers your ass.
KFG
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.
it's that simple. there should be no difference in the q&d and the correct solution. as for documentation, programmers read code, comments are for pussies.
//comments are for suckers
//coders read code
Your post tells the whole world that you have never been laid.
I most often find myself being asked or pressured for the "Quick & Dirty", rather than "Correct & Proper".
As a small software company with a somewhat specialized niche (that hasn't fully recovered from the recent tech slump), we often find ourself chasing the money, which usually requires getting code out fast, consequences be damned. In the vast majority of cases to which I've been a witness (and in some, to my shame and regret, a party), it has come back to bite us in the end, almost always for more time, effort, and money than it would have taken if we'd done it right the first time.
But, our situation is one where if that "Quick & Dirty" check didn't come in when its needed, there'd be no one left for "Correct & Proper" later on. Of course, it's a vicious and ever growing cycle. Yes, it makes me and many of my collegues feel dirty (generally the other developers and technicians...not so much the sales people and PHBs; they just tend to feel relieved), but for most of us, eating is too much fun to give up. =\
Common logic would say that the following is undeniably true:
1. Fast
2. Cheap
3. Good
Choose two
Now, your manager says:
Give me all three or your "fn" fired!
So you go off and do it fast and cheap and hope he doesn't find out it's not good....
.sig
An ordinary developer, however, usually doesn't make those sorts of decisions, and a sensible hiring manager would know that. If a product fails because of market conditions, its no reflection on the developers at all.
"It's Dot Com!"
Thirty years of applications design, development and implementation experience have taught me to always do it right.
The challenge is to quickly figure out what is right for the particular circumstances. If the task is a one-time data conversion, where you can inspect the data before and after, a short perl script may be all you need. If you are developing the 'coolant overheat' routine for a nuclear power station, make sure every possible condition is identified, and handled in a failsafe manner, before design is even begun. And test, test, test.
It helps to 'know your stuff'. I once had to appeal a management decision because it was wrong. His boss disagreed with me. So I took it up another level. He disagreed, too. So I put my job on the line and went a level higher still. I won that one. I was designing and building an ISAM engine. It had to work, first time and every time, without tuning.
Have I broken every rule in the book? Certainly, when it was appropriate. EDI in 3 Weeks - No data, no specs, no requirements, no customer - No Problem! I do it by understanding the rules behind the rules. But it's a risk. It helps to be lucky.
Morris Schneiderman
www.ProjectsDoneRight.com
Can't say I can blame them. I mean, I know how pissed of I would be if I came back from christmas vacation and the janitor had mangled my code.
Oh, and could you refill the pack of toilet seat covers in the near stall in the second floor women's room? Mrs. Martin keeps complaining about it.
..within reason (it doesn't take a brain surgeon or rocket scientist to figure out what "within reason" is.). I learned a long time ago as a hardware and software engineer to CMA - Cover My Ass. My answer to any question regarding "Can you do this for us?" is "Yes, if you give me the request and specifications in writing." Especially when it comes to doing something that doesn't exactly follow all the normal procedures and/or policies. I always follow up the request and specifications with something in writing stating what I can/will do, how I'll do it, and an approximate time that it will be done.
;) ), then I deserve to be bitched at.
This way, when someone bitches about something later (and someone always does bitch about something sometime), I can pull out the written request/response and CMA, putting the blame (if there is any blame to be put) on someone else.
Of course, if I f' up (which I've never done
PGA
Office Space, cult classic among cube workers, See also.
"Sic Semper Tyrannosaurus Rex."
If you have some sort of other measure of value then your answer varies. I strongly suspect though that in business money is the only measure of value, hence the endless amounts of craptacular commercial code out there.
"Belief means not wanting to know what is true." [Nietzche, The Anti-Christ, 1889]
Here is a lengthy discussion on the topic. Basically it comes down to personal and corporate philosophy and what makes the most business sense.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
Good, fast, cheap. Choose two.
Nate
You never know who will get one.
I have experienced the same situation... I have worked for a boss who demands a quick solution to a customers problems...and I have built these solutions, both quick&dirty and also quality, where I have spent a long time "getting it right". In both cases, I have observed that you will get dumped on because, "it took too long to build it", "it cost too much", or because it was q quick and dirty implementation "it's not expandable, it broke, the customer does not like it's features" etc. Now-a-days, people don't want things to cost a lot and they want these things right now, no waiting. The most anoying part is were you are to blame for all this...nobody cares to remember the reasons a project screwed up, (if you point out why it screwed up, that makes you look like a sore loser and most likely the source of all these problems in the first place). Sure, I can accept that a quick&dirty solution screwed up, but a quality solution works, but you get blamed not because it worked, but because it was quality and cost too much/took too long to build etc. Best advice is to find a better job, but probably there are very few good places to work at that still do quality work.
a quick and dirty solution will bring in money for the company, and a correct (ie, properly documented, well engineered, process followed, etc)
Documentation and processes are there for a reason. If they're getting in the way instead of making software better, you need to get them changed. The ultimate goal of a software developer is to make working software, and often the best way to do that is NOT to over-engineer and follow ivory-tower software engineering theories. At the same time you don't want to hack together an unmaintainable monstrosity.
But you really need to welcome changing requirements and keep the overhead of processes to the minimum needed to keep development going in the near- and far-term. ("Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.").
Check out e.g. www.agilemanifesto.org. Above all, remember that "working software is the primary measure of progress."
Sumner
rage, rage against the dying of the light
If you arent first, someone else will be.
And they will get the contract. And the nice shiny car.
If you loose the customer later due to their instance on quick, after they find it wasnt well designed, there are plenty of other customers.
And you still have the car.
---- Booth was a patriot ----
This is also known as covering your ass.
It has been my experience that those who cover their asses have jobs longer than those who, procedures be damned, do what it takes to get the job done in time.
Also, take up drinking. It helps to numb the mind when you are constantly shown the jerks who don't do anything(but do it by the book) as the positive example.
You have two separate issues.
The first is the need to implement quick & dirty solutions, that's OK, sometimes software development is like that. Sometimes you stick with the quick & dirty solution way beyond it's anticipated lifetime.
Your second problem is you work for real morons and/or cyncal assholes. Don't let their bullshit phase you, remind them of their decisions and your accomplishments. If you can't take the aggro go work somewhere you're appreciated. Leave them with all that quick & dirty code to maintain and bask in their suffering with no regrets.
Work on improving your ability to deliver decent code even when it's the quick and dirty solution. There will always be a need to get things done quickly, and it is the rare occcurence on a project that you actually have time to do things "right", so don't wait for it, expect it, or be wistful about it. It doesn't exist.
I like to think of it as you're only as good as what you can put out on average. It doesn't matter if you "can" be a great coder, it's only how you execute from day-to-day.
I ran into this problem a lot when I was an IT Director at this design company. We would get a call that a freelancer was showing up that morning, who would need a machine with Photoshop, Illustrator, Quark and other applications and we would have ZERO time to get it done. It was hard enough finding a machine but it was much harder to explain that technically we couldn't put the required software on the machine. Of course, we would get (ahem) "push back" and be told that we would just work it out later, etc.
Of course, we would bring it up, but the accounting people would just look at us blankly at tell us to get the project to deal with the budgeting, etc, but by then, the freelancer was gone, or we got a litany of excuses why they couldn't afford "real" copies (never budgeted into project) and "what did it matter anyway, it still works, doesn't it?"
When my company was finally purchased, it was up to me and another guy to go through the software license situation and it cost a BUNDLE. We had to stick the absorbing company with the cost to finally get us legal and it was just horrid.
So, as far as what's the right thing to do, I think that by the time you are asking that question, it might be too late. Best to snag the various higher ups and explain the situations before any of this arises and see if they react to you being "proactive" and all that. I was able to explain the fines and how the company could lose a ton of money, which you would THINK would work, but this was right around everything falling apart...
I guess my only suggestion is to write a document explaining that you are indeed using short cuts and there might be some fallout later on--and have the producer or the project leader or whomever SIGN it to make sure people know the implications of their decision...hopefully it will make them think twice when budgeting and scheduling future projects...
good luck!
m
---mike
...one of the major reasons why a lot of work is outsourced to overseas locations. Many countries we do business with *cough*China*cough* are perfectly happy with killing people to keep them from saying something anti-government. It would be naive to assert that they would then be squeamish about overlooking a bit of shady business practice to undercut "correct/proper" businesses elsewhere and capture that market share.
managment never lets us do things well. They want it now more than they want it right or good. Today at work, the office manager told my chip design group that we will tape out the chip we're currently working on by the 31st of this month, a bit less than 3 weeks from now. A rush job now, some testing and timing verification will now go undone, and we'll most likely spend the rest of this time dong DRC and LVS, the two checks that see if the design is manufacturable (DRC) and if the silicon layout matches the schematic/netlist (LVS). Screw power analisys. Screw timing checks for some things. Screw the remaining functional checks to see if it actually does what we think it does.
:/
Yea, the poster got it right. Managment doesn't want proper documentation. They don't want testing and verification and quality. They want due dates, and apparently whatever is avilable on that date will have to be "good enough"...
Think product life cycle and ongoing revenue stream. v1 - quick & dirty v2 - almost there v3 - works well enough to know what features are truly missing v4 - mature product charge the customers for maintenance and make money
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Thus spoke AynRandIthustra
autopr0n is like, down and stuff.
And for the truly excellent managers: "Correct and Proper" does not exist. Ultimately, there is always a better way. As several posters have mentioned if Q&D works to the customer's (internal or external) satisfaction, it is the final solution.
You don't spend your money on fixing bugs.
That's what maintenance fees/contracts are for.
Oliver's army is here to stay Oliver's army are on their way And I would rather be anywhere else But here today
In a process-oriented company, there are typically meetings that determine the time needed to release some feature, product, or what not. If the need outweighs the time for proper development, any corner-cutting or release-delay decision would be well documented, and reported up the chain. There should be no hot water for this process. It does work. Let the managers take the heat for marketing decisions.
However, it can happen that a developer makes unrealistic time predictions (could even have happened to you - yes, and you over there too!). Perhaps the lack of documentation, specifications, or such, was kept secret, or even lied about. Well, in such case, the developer deserves all the scalding, roiling, frothing water the company can give, since this undermines their very trust relationship.
Not saying you were one of those jokers, but I do want to iterate that company-critical decisions are often made by more than one person. This should be well documented, and as such, you really should have no problem.
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).
If making money for the company is not a good thing, leave before they go broke.
However, did you send management a memo or email *before* you started the job quick and dirty? Did it say how long you estimated for Q&D, vs how long by the prescribed process? Did you estimate how long to clean it up/make it right after delivering Q&D?
If so, you could have just pointed to that CYA. If you tried to do that verbally, be aware that PHBs and Marketroids *cannot* comprehend/remember that kind of thing if it is verbal.
Don't you remember from your Software Engineering Professor in college saying that everything that you learn in the class, the proper and theoretical stuff, is semi-useless in the real world? Remember that big software engineering project that sucked the life out of you for two months because of unreasonable deadlines?
One thing which I usually find is that developers don't understand what managers are for.
:-)
Most developers think that a manager is just someone who has no clue but the power to bother you.
To put it simple: The developer knows and the manager decides.
It's the job of the developer to understand the situation and come up with several (at least two) possible solutions for a problem, state them in clear words, list the advantages and disadvantages and make sure the manager understands them.
Then, the manager will make a decision. An educated decision.
But often, people don't bother to tell their managers what's wrong and why it is wrong and then, they wonder when the manager makes a bad decision.
I have found that it's very simple to get along with management as long as you keep them posted and you know your facts. When they grill you and you can stand your ground (and you can only do this when you know what you're talking about), then they will start to trust you and your life will suddenly become very easy. Note that even saying "I don't know but I'll find out" is "knowing what you are talking about".
Managers are just people, too. They know that they don't know as much as you do about the problem. They feel uneasy about this. Make them understand and they will be your friends.
Try it. It might be an effort but it really helps to get what you want (a bigger machine, less distractions by managers who want to know what is going on, etc)
Okay, I'll level. I've been a programmer since 7 years old back in the old Apple ][+ glory days and I've grown up with it. I program at an astronomical rate, finished many (now on 9) commercially available products, and getting faster and more experienced each year.
:)
Of the products that I've worked on, they started off as quick and ditry (Lets call them.. uhm.. "PROTOTYPES") and later tried to evolve some form of standardization process that was constantly ridiculed regardless of how many graduate college courses or whatever the Quality inititive was modeled after.
Two things I noticed:
1) Management is never satisified with the incredible amount of documentation you produce.
2) Management is never satisified with how quickly you write the program.
I think I'll add the given the nature of my work, which is considerably tech oriented, I noticed that Marketing (CMO/Marketing Directors) are hopeless and useless when it comes to actually understanding any of it, regardless of what examples I use. I'm not trying to be sarcastic, but I've actually had to resort to:
1) Explaining my product in terms of fairy tales.
2) Comparing my product to animal behavior.
3) Creating fantasy stories that include rather detailed information about the people's lives of the users of the program. I even had to include who was having a relationship with whom, in order to describe how security situations and stuff could exist.
And yes, these examples were so well received we put them in marketing literature and I feel ashamed.
Don't laugh, this is RL.
Here's my beef -- as a fast and organized thinker, but also a researcher and experienced developer, I know the dirties before I even go into writing the program. Now that I'm self employed, I've noticed a -huge- jump in my performance, depth, and code quality. Probably easily an exponent higher in all areas.
Due to the wonderful lack of team meetings, I can pick my favorite supporting tools, use the software I feel most comfortable with, and make rapid decisions for everything. HEAVEN! If I have an idea for a quick and useful new feature, I just add it. I can even wait for the program to be finished before writing the manual so my screen shots are even current.
After 12 years in the industry, I honestly think Coding Freedom is more important than anything else, and I feel sorry for your plight about the balance between management's "perception" (which is exactly what it is) vs. pursuing the obvious direction with enthusiasm. Battleships don't win races.
Honestly, I'd love to see a company with a pure Research model to allow the creation of profitable prototypes created by brilliant minds with maximum freedom. Under current business practices in the USA, its highly unlikely.
It seems like the "Thomas Edison" approach to trial-and-error until you invent the light bulb and illuminate the world is considered laughable in today's world.
This demonstrates the m$ model and the faustian choice. History has shown that bug-ridden, mediocre software shoved out the door, grabbing market share leads to fabulous wealth only if you are not held liable.
As a QA guy, this is something I wrestle with constantly. There's a compromise, almost without exception, made on every project/product between having it done fast and cheap vs. having it being done properly (proper CMM technique, full documentation, usability testing, user acceptance, design reviews, etc.).
QA is a study in compromise between these two points, as well as a balance between the needs of the user and the needs of the development organization (money/time, interface design, platforms, etc.). I can provide a certain level of quality assurance on any project, no matter what the timeline looks like, but those who lay out that timeline have to be willing to accept the risks that poses for the organization. A fast project often does equal a much higher level of risk.
Something to consider, though: programmers, being creative people, often are at their best under the pressure of a tight timeline. It keeps them from drowning in the details, and can lead to some very elegant solutions. It can also reduce the amount of PHB micro-management, which has a whole string of benefits.
Compromises have a way of staying around longer than we expect, waiting for a chance to come out and say hello in disturbing ways. A shorcut may just mean massive amounts of rework when porting to a new platform, database, etc. Remember all those old COBOL programs that were supposed to be obsolete a few years back?
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.
I used to be a nice guy, you know, take the girl out, get to know her, develop a relationship and then move onto the physical stuff. Most of those startups went out of business in about 2 weeks.
Then I changed my business strategy, went for the home run on the first date, and then fixed the bugs in the relationship later. This has proven a much more successful strategy, as the first version managed to survive 8 months, and the current version has been going for nearly two years now.
Much better to put a functional product in use right away and then support any issues than to try and fix all the issues first in hopes that you'll then be able to sell the fully functional product. I think we'd all prefer that our products are used more.
Could you maybe rephrase that in terms I'm more familiar with?
that make sense in a commercial environment is the good enough principle. What constitutes good enough is what calls for good judgement. If you're writing a server app that is expected to be mission critical, good enough is very good. If you're writing a one off desktop app, good enough can be quite sloppy. IMHO
Ofcourse Q&D methods are called quick and dirty for a reason. 'Quick' for quick rise and quick(er?) fall. 'Dirty' for all the dirty work done now and more of it later. If the company is old enough, it must have already realized the fact. So, the answer (for which method to choose) is simple -- if your goal is to make some quick bucks and disappear, you can go for Q&D. If you want to stay long, then you have work to develop and maintain good will among the customers, put eforts in choosing the proper development process and maintain such ohter ethics. Now, if you do not have enough power in your hands to modify the development process, how about trying the down-up procedure. Try convincing the co-workers why it's dirty and suggest the better process of doing it. Even if they don't follow you now, once the idea is put in their heads, you can sit back. They will observe them(the reasons for change of process) for themselves as they encounter problems. Once this level is achieved, the idea goes up the tree to the person who has the power to change, process repeats, and eventually the change (if good) will occur. As anything significant it takes lot of patience and faith.
Perhaps I'm in a conducive environment, but I have an effective means of minimizing this backlash.
*Always* scope out the person-power to do the full blown project, and stick to your guns. In those situations where there is too little personnel or schedule to do the "proper" job of it, you can leave the postponement of "ancillary" tasks (testing, documentation, etc.) to the pointy-haired management corps.
I cannot claim this has kept me from conflicts with my peers and superiors, but my integrity has remained largerly intact.
and a Full System. Then at the end of the Minimum System, people know what they got.
Oh well, what the hell...
I've worked in big (> 200) and small ( 5) software companies, and I'm convinced its size thing.
A larger company can afford to pay for extra process (docs, quality control), and usually can't afford to be without it.
A smaller company can often get away with being a bit rough around the edges because its dynamic enough to take up the slack when things go wrong.
Clients already know this of course, so they see it as a quality/price tradeoff. The difficulty for software guys in a smaller company is to have to justify their way of working to a client who expects impecible process, reports/updates, and it all delivered yesterday! Which is undoubtedly what the sales guys promised them when trying to project a 'professional' corporate facade.
Just remember though, no matter how professional the facade - everybodys a cowboy. Thats the nature of software, the industry's still too young for anyone to know what they're really doing. Processes help, but they are a tradeoff..
These are in order of priority...
1) Make it work. It's very important to have something to show/sell!
2) Make it work well. Once you have something to show, it's important that it generally behave as expected
3) Make it work right. Finally, once you have something working and doing what's expected, it's important that sound design and engineering principles are used, particularly in maintenance to ensure continued ability to meet the needs as they evolve.
This is where I'm more and more becoming an advocate of Extreme Programming. Primarily the concept of code evolution - that you quickly evolve the code to fit the needs as they evolve.
My most common evolutionary path is to start with a hack, and make it clearly known that it's Q&D, and then when needs overwhelm it, we consider it a "proof of concept" and rebuild/rewrite as needed.
Typically, when the Q&D solution isn't enough, the resources exist to pay for the "right" solution.
Another great reference work is the Big Ball of Mud, covering the various reasons why software develops the way it does, and highlights the various forces at work.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Do what your boss says, but document the communication where you mention your qualms, and document everything else. In other words, CYA.
Amazing magic tricks
is this what XP programming was all about.
Get the code running, use the principal that 20% of the code does 80% of the work,
Get it running, release often, and *DONT* too much time for the future stuff that you dont need?
Sigs are dangerous coy things
If this is just a "quick hack" that is expected to have a lifespan of a year or so, then you can get away with a Q&D "solution".
;->
But what if the code is supposed to live a bit longer, say a decade? Would you want to try to:
- wade through such "code" left by someone else
- maintain it
- find and fix bugs
- explain to management "Uhhh, sorry, but it will take at least two months to fix this one" when they sputter "But, but, it's only a single menu choice that has to be added!"
- just understand large parts of it, while noticing that the pile of empty scotch bottles pile up just to keep you sane
Management is flexible when they get the right kind of explanation of why one sometimes must go that extra mile to both design and implement it correct from the beginning. One argument they might listen to is "If we do this Q&D, it will take at least ten times longer to do any maintenance or even a next release. Are you (looking sternly at the manager) willing to take that decision? If so, I want that in writing before anything else.
That way, when (not if, when) the brown stuff hit the ventilation device you have a piece of paper displaying you was forced into this position under protest, and your hands are clean.
This will get you the attention of the ones in charge of the money...
This could of course also just be a display that you are not the right person for the job - that someone with more experience in the area would be able to do the implementation both quick and non-dirty. Sorry, but it had to be said.
The "proper" thing to do is probably doing what your boss tells you to do.
--Slashdot: News for Turds. Stuff that Splatters.
for any project, IT or otherwise: you can only pick any 2 of [cheap|fast|good]. Think about it.
I am currently working to do it right. We have been told we have the time it takes to do it right. We will have spent, by the time it is over, a year and a half on this project. It includes researching, designing, implementing, and deploying a multi-tiered backend. The phrase that got some people going for our idea was a quote from elsewhere on the Internet.
"There's never time to do it right, but there is always time to do it over."
I know I am lucky in that I am given the freedom to set my own deadline. This is a system we needed years ago but instead of rush it my boss is running cover all the way up the line for us so we have the time it takes to do it right. Middle management probably will not understand when one group says the same thing could have been done in a month or two and we say it will take 18 months. I hope that in the end they will see that unlike the other solutions implemented by the quick-n-dirty group, this one works.
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)
How do you get girls naked when you can't even afford a digital camera?
autopr0n is like, down and stuff.
You said you want money, so here. Do it like Microsoft products (Yes, sell your soul to the devil ). Buggy as hell and over marketed.
Then, once you have a considerable user base (all frustrated) and locked in , you can correct the major problems and make it version 2 (or 98 or XP if you feel extra Devilish). So in other words you will be selling the bug fixes to your customers as a product. Don't forget that a good marketing plan is more essential than program design. I would suggest an extra dose of Dilbert on daily basis to get you started
If you feel that the competition is more that 2 times better (one is not enough to worry), then for god's sake don't improve your software! On the contrary make it so that your customers can not switch from it to the competition's without major problems.
Do not feel bad about your customers being forced to problems and inferior quality products. They will love it. Look at how many use Windows.
I mean, the answer to your question is right in front your eyes.
Slashdot Sig. version 0.1alpha. Use at your own risk.
Remember EDS..guess which way they did it?
later pain is never good for a company for one purchaser of the software system can sue and get your company over a barrel!
Don't Tread on OpenSource
XP was built on the knowledge you just mentioned: That the Q&D solution is necessary, and that if you try to follow set procedure (or the "waterfall model" as it's called) where you have a requirements, design phase, implementaion phase, testing phase you will most likely fail.
Basically, what XP is all about, is to acknowledge that the specification is useless, beacuse after a couple of years when the project is finished, the end result doesn't look anything like the sepcification anyway. At least if you want to survive in a dynamic market. We have all seem that in the real world, the requirements change during development, and if they do, you need to go back and change the spec, and then possibly reimplement large parts of the code.
So, how do you go about solving this? Well, first of all you have to understand and believe in a couple of mantras:
Here is the list of development rules.
The implementation is the specification
This means that instead of writing a specification before programming begins, you let the application evolve (very similar to most Open Source projects actually) and if the requirements change during development, you change the code to adopt.
Refactor mercilessly
This is absolutely nessecary in order for the previous point to work. What it means is that you should not be afraid to change the layout of working code, to make it easier to add new features. With good refactoring you don't need a complex design in the beginning, which means that you get to market more quickly.
I strongly recommend you read Martin Fowlers book Refactoring, it's a real eye-opener.
This leads us up to the next point:
Do the least thing that could possibly work
If you are thinking of implementing a couple of abstract base classes and interfaces to make your object design super generic, so that it can be used for a lot of differnt things in the future. For example implementing a plugin architecture in your file parser or somehting like that, you need to ask yourself the following questions:
Am I going to need this abstraction now? and If I need it in the future, will it be easy to refactor the code so it gets that functionality? If your ansers to there questions are "no" and "yes" respectively (which they usually are) then you should not do it.
Essentially: don't do anything until you need it.
Test driven development
All this refactoring, and no solid specs can be a bit scary, especially in the beginning. A common question that pops up is: "how can we guarantee that the code works if you keep changing it all the time?". The answer is: unit testing. The rule of thumb here is: Implement the test first, then you implement the code so that the rest runs. Whenever you are going to fix a bug, write a unit test that triggers the bug first, and then fix the code so that the test succeeds. You then make sure you run the ever growing test suite several times per day. It helps a lot in catching regression bugs.
For Java, I recommend JUnit.
Now, the biggest problem you face is selling XP to your PHB's. They will more than likely feel that they are losing control, and they will be afraid that their nice Microsoft Project documents will become useless (no one seems to remember that (almost) every single waterfall project will overrun both budget and time constraints). However, there is
Document, document, document... and I'm not referring to the code. Make it clear to the weasels that THEY have a choice to make. Quick and dirty will get it out the door, and you'll have to come back and work on it again for the final version. Or if it's processes and technique, make sure they know that's the reason why it can't get done in time. Make the choice clear and let them make it.
I've heard a lot of tales about people who aren't allowed to speak up about these things. BS. Screw 'em. If you're not allowed to speak your mind about these things and tell people the truth, the job isn't worth it.
RP
Also, make sure to tell marketing that by having a better product, you'll naturally draw more customers -- allowing them to look better.
This is my digital signature. 10011011001
Sometimes the quick and dirty solution works as well as the elegent solution, the only difference from the users perspective is that one costs less to develop. Obviously for major development projects that you're planning on basing your comp... drugs, nm, this is lame
Pardon me for saying this, and I hope you won't think that I'm trolling, but this is a stupid discussion.
Every post I've seen assumes for some reason that there is a binary choice here: either it's completely quick and dirty and crappy, or it's perfect and clean and way over-schedule. But what we're talking about here is not a binary choice; it is not black vs. white.
Being a good software developer means striking a balance. There is a quality of code vs. development time tradeoff here, but it's a continuous spectrum between the two extremes, not a binary choice.
The reason experienced senior developers make more money that junior developers is that it takes a lot of time and experience to learn to make the decisions about which point on the spectrum you should shoot for, given the current situation. Every situation, every product is different.
In general, too, I find that it's best to change this point on the spectrum over the process of development. Early on it's more important to design carefully so you don't paint yourself into a corner. Later in the development cycle, once the design has had its kinks worked out, it's fine to relax things a little. One week before gold master, pretty much everything is fine to hack, as long as the hack will work. At the last moment, if you can fix two bugs with good hacks or fix one bug with a clean, well-designed, thoroughly coded and commented piece of code, you really should fix the two bugs with hacks and recode them _after_ the gold master.
Software development is like most things in life; there are no clear cut rules, no certainties, and no real ways to come up with a formula to always succeed. At every point in time, you have to pay attention to what's going on and try to make the best decision you can, given your current situation and your projection of the future.
Not really very satisfying, eh?
MS did it quick and dirty. Their stuff was teh crap, but now that they have all the money, they are starting to fix it.
If you have the time, do it proper.
or, you could just be a real good programmer and make quick and dirty mean correct and proper.
> "I allege that SCO is full of it" -Linus
$uccess may be temporary, but the $ is forever.
Seriously though, you should give customers what they want, and what they want is what they pay for. If you want to be all perfect, refactor the code for free when the job is done. Why waste your time with niceties when people aren't paying for it.
autopr0n is like, down and stuff.
Unfortunatly, if you are a consultant...that is the real world.
;)
I used to get soo frustrated....until I quit and moved to a big company....now I only get a little frustrated.
I blame this mainly on the economy....now adays its more about the "bottom-line" (shiver)...
-Rob
You might make some enemies, but you will make some friends in high places, especially those people who control costs. This will earn you a reputation as a person who truly has the company's best interest at heart but will also allow you to know that whatever the fallout you will have done your best to make sure everyone is advised of the situation. And more importantly, the interested/relevent parties will not be able to say "I didn't know, you never said that to me!"
Don'tcha think?
Well.... IMHO there's fundamentally no answer to this because its an incompletely stated, perhaps not well formulated question. I don't mean to offend, but I think its too confused a query to be a useful debate. Its further confused because the Slashdot crowd mostly seem to assume that there's a valid technical answer to a business and quality issue? Why is that? To me, the underlying issue here is definition of Quality, as stated there really isn't one, or at least whats implied varies over time in an uncontrolled manner, so nothing definitive can be concluded as to whats ok, or not.
Basically, its seems that Q&D approach works for your company and your customer, but not for you, thats awkward, maybe consider changing your job. Most any other answer is a slippery slope argument leading to a religious war, for the ever waiting language/methodology/tool fetishists and flame crews.
I do think that management in companies that cause such issues and debates, mostly reveal themselves as incompetent and not worth doing business with, whatever your quality stance, as they clearly have not defined their business process model sufficiently to trust the results or communicated the quality approach to the staff.
My advice (FWIW), fire your company, or the PHB's and move on with your career, if the situation cannot be improved by discussion. Otherwise quit worrying about their dumb mistakes that you can't fix. In other words, maybe its time to just Get a Life.
FYI, I am a technology manager, a PHB to most of Slashdot I guess, and sorry to bust any bubbles but not every shop is this dumb internally.
Of course, thats only true for some limited ranges of stupid, and some sets of PHB's. YMMV.
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
An old boss of mine had the quote. "There's no such thing as quick and dirty. Just dirty." Which means, as soon as somebody revists the quick and dirty solution you provided (and they always will, no matter what how much "this is just a once off" posturing you do) it will take longer to extend, longer to understand and harder to maintain.
So, go ahead and give the "fast/cheap/correct: pick 2" argument to management. That argument is a false choice. If you're the person responsible for the execution of the project, it's up to you to find the balance that will satisfy your Customer. Here is the process that I use; YMMV:
1. Identify the Customer. The Customer is defined as "the person/company to whom I have committed to provide something". Usually, there are several in a project. Your Boss. The Project Team Leader. The Client. The End User. Regulatory Agencies (OSHA, FDA, NRC, etc.)
2. For each Customer: Identify the Customer's Requirements. This is usually the hardest part of the process, as often the Customers
a) Truly don't know their requirements.
b) Have trouble being specific.
c) Ask for conflicting requirements.
This is the part of planning where you should spend the most effort. It is an iterative process.
3. Requirements can be broken down into three categories: Functionality, Schedule, and Cost. They are listed in order of priority. Notice that Cost is last. This is actually the Customer's least significant requirement, but the one they think is most important. Remember this.
4. Resolve conflicting requirements: "Yes, Boss--I can put a back door into the log. But didn't you say you wanted it to be secure and auditable?" "Yes, Mr. Maintenance manager, I can put quick-release guards over all the couplings. But, the OSHA inspector is going to throw us both in jail if I do!"
4.5 Set your own limits as to what you'll deliver and stick to them. Know what sticking to those limits will cost you. "I will only write proper code, for I am REAL PROGRAMMER" might not be such a good idea. "I will not design or participate in the design of unsafe equipment--even if it costs me my job." might be a good idea.
5. Document commitments to Customers. If the requirements are vague, make the commitments specific, but limited to what you know you can provide.
6. Specify Change Control procedures. If you ask for a change, you get a document showing impact to Functionality, Schedule, and Cost. Boss gets a memo and he has to understand it. Client gets a change control form--which he has to sign, and maybe he has to write a PO addendum.
7. Follow Change Control Procedure! Stick to it! Everybody wants you to "just add this bit/indicator/field, it's no big deal". A thousand little changes can kill you. Don't let it happen. There will by crying and gnashing of teeth. Be ready for it. Endure it. It will pass.
8. The Customer will screw up. All of them. So will you. Deal with it by fixing the problem as quietly and professionally as possible. Don't ever point fingers. Especially when you're right.
9. Protect your Customer from embarrasment. Let him know you have done this without embarrasing him. If you deliver the goods, and protect your Customers from embarrasment, they will sing your praises to high heaven. Guaranteed.
10. If you have a big ego, turn it off and remember you're a professional. If you can't, get out; this is not your field.
Sometimes, you do the best you can and realize that the "corporate culture" where you work means that you get yelled at a lot. BFD. It's a job, not a play date.
Sometimes, you realize that management is going to drive this ship onto the rocks and kill all aboard. Jump ship before the wreck.
Sometimes, it's good just to have a job.
"Reality is that which, when you stop believing in it, it doesn't go away." - Philip K. Dick
If this is something that could become a standard product (or shared code), then make incremental improvements with each customer. I'd look at where you spend most of your time debugging and either fix that, or do something to make debugging easier.
Most (big) companies have a policy that managers can only confirm the employment, start, and termination dates of former employees. The legal issues are thorny* when a not-quite-positive reference is given for a former employee. So the policy is you can't even give -good- reference either.
(* by "thorny" I mean "their lawyers will eat you alive")
So, always make sure, if you're good, to get personal references; there's usually no policy about co-workers. If you think your boss will sing your praises, well, they probably can't.
Kineska: Cinema, soapbox, music & musings
I'm only 20, i still have 2 years of ignorant bliss!
This is my digital signature. 10011011001
There is a widely accepted set of guidelines developed at IBM known as the Capability Maturity Model. As organizations develop and grow, they should develop repeatable processes.
There are 5 stages in this model, and clearly your organization is at stage 1: Initial, where sound practices are often sacrificed to meet unreasonable schedules, and project management is weak.
You might want to find out more.
I frequently find myself in the same situation, and have switched to using Python wherever possible for the Q&D solution.
I've found that, when I write Python code, I generally get the structure of the code pretty right, though I may wind up skimping on documentation, may code stuff inline that should be separated out into functions, and so on. The step of converting Q&D code to production quality using Python is a whole lot smaller than in e.g. C.
Even if the final version has to be in C/C++, then I find implementing a Q&D version in Python first allows me to write better C/C++ code later on. Again, I suspect it's because using Python enables me to get the basic structure of the code 95%+ right on a first attempt, and then it's largely a matter of translating Python to C/C++.
Whatever you do, don't try creating a Q&D version in C/C++ if you can possibly avoid it. C/C++ code tends to be degenerate into unreadable/unmanageable crap much quicker when you're using it for Q&D code; they're great languages for production quality code, but just not that well suited to Q&D code.
IMHO, YMMV, etc...
One important distinction is between development of a "packaged" product or of a custom project for a customer. In many cases, a customer project will be most successful if you get something out the door and delivered to the customer as quickly as possible. Since they probably didn't know what they wanted in the first place, this will give them a chance to play around with what is, in essence, a prototype before you sit down and craft a masterpiece that no one will actually use. For product development the picture is very different. Here the temptation is to throw quick-and-dirty hacks into your product for every potential customer to land a sale. The result is a bloated, spaghetti-code-ridden product that takes longer and longer to extend because its design does not lead to easy code reuse and specialization. This is a death spiral for any software development company and must be avoid at all costs. With products it is indispensable to make orderly releases based on requirements driven by a synthesis of customer needs, not the "urgent" requirements of one customer.
Peer Pressure
- Quick 'n Dirty = v1.0 - Correct and Proper = v2.0 By cleaning the code, you can improve speed and make a more robust program, both great reasons to have a pay-for 2.0 upgrade.
And if Bill Gates just understood this, maybe he'd make something of himself, as opposed to living in his parents basement.
autopr0n is like, down and stuff.
I agree.
Quick and dirty hacks may not solve your problem, if they don't solve the problem ie long term maintainability, they are not a solution.
If it doesn't do what it should, it is not a solution.
... then you're not doing it right. It's that simple.
ALL engineering is a series of trade-offs.
Imagine the PERFECT project, where everything was 100% perfectly accounted for, every situation was coded for, and fully tested, and the goal of shipping with exactly zero defects was met.
A perfect product would take an infinite amount of time to complete.
At some point, you've got to make a trade-off between quality and timeliness (or whatever other factors limit you). Perfection is an unrealistic ideal. Shoot for it. But don't shoot at it.
Where you draw the line, depends on a host of factors, some of which are impossible to determine until after you've shipped. It's the job of the engineer to draw that line, and make the best possible product, given the parameters of the requirements.
Isn't this a rather basic question?
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Sometimes there is no choice but to do it the quick and dirty way, and being first to market is such a situation.
Company A and Company B are working on a product that does basically the same thing. Both companies know that they are both working on a similar product, and they both know of potential customers that will go with the first one to provide at least a decent solution. A correct and properly tested solution might take a year to develop, a quick and dirty one that does the job six months. What do you think is going to happen?
Yes, the development team might say "Well, we will fix it on version 2, and do things the proper way." But then, the Feature Wars start. The customer wants a set of features, and the competing company, which by the way, finished it's product shortly after you, is promising them for version 2. Whoever gets those has an advantage. And so it starts again, a race to be the first to market with such and such feature, and whatever got done wrong on version one stays that way (because there is no time to fix it), and more stuff done the wrong way goes to version 2.
It looks to me that the "Quick and Dirty" way can't be avoided in money making, "first to market race" projects. And that covers about every for profit company out there.
Do you want the job done right, or do you want it done fast? - Homer Simpson
I started a project over a year ago. When we started we were well staffed and on schedule. I was being thorough and documenting things very methodically. Then management started to take staff away, and things got a bit messier. Then the client changed their mind and kept the same schedule. And I started putting most of the design together off the top of my head, figuring I'd write it down later. Well, now we are almost done, there is a fundamental flaw in the design basis that the client is blaming on us (me). And my bosses want me to do things even quicker and dirtier, just to get it finished. I get blank stares when I tell them that that's what got us into this problem in the first place.
Oh, and I'm not talking about coding. I'm an engineer and I design oil refineries. Sleep well on that knowledge, I know I don't.
Laugh while you can, monkey boy!
If I'm not mistaken you brits have a sort of psudo-reality show called The Office. I don't really know that much about it, and you don't know much about Office Space, but I think we can just assume they are similar :P
If more professionals stuck to Quality and Proper Programming, then it would become the Accepted thing. Too many times corners get cut, and there's Hell to pay afterwards. Most of the time, it's rightfully deserved, too!
Of course, you can't discount the Bosses Breathing down your neck for something that they wanted Yesterday, but you have to make a decision for yourself: "Is it worth my rep, my time, and my personal worth to cheapen this project with half-assed corner cutting?"
If you ever need a frame of reference, think Windows 9x. Too many corners cut to Try to bring it out in the right Year, and Still never got it all worked out. That, and so much time and effort wasted on "Creative Sabotage" of the OS to prevent compatability with 3rd party programs, and "Easter Eggs" buried in the code by Bored programmers that would have been better off spending their time killing Bugs...
But I digress...
Dear Agnes
I don't know whether I should breathe through my nose or through my mouth. Please help.
breathless
Dear breathless,
it all depends, are you walking or running?
yours,
Agnes
tells you the day you were born, and with some simple mathematics can discover the exact moment your parents copulated. And with some persistance, you can trick them into revealing some sort of detail about where they were a couple weeks before July 4's Marijuana Concert of the Lifetime with the BeeGees and Yes.
I know where my mother was before my conception, in a giant forest with mosquitoes and bears. (Marriage Honeymoon). Gosh I hate mosquitoes and bears.
This ought to be the customer's decision. If they know the trade offs, there are times when a quick and dirty solution is appropriate.
But, it is a rare customer who has the experience and knowledge to know what the trade offs are. If you're lucky enough to work for a company that explains those trade offs to the customer, you can push for the decision to be made there.
If you work for an outfit that takes requirements and then never talks to the customer, you have a problem.
Customers often don't think about maintenance or upgrades, or tech support. So, they don't often remember to add it to their list of requirements. In my experience, it is a rare development shop that will tell the customer that they're probably going to need that, and more. Most vendors I've dealt with abhor chasing down requirements (and the customers loathes the process even more). So, they build to incomplete and incorrect requirements. Invariably, the first time customers gets their hands on real, working, code, they start to realize what they really need. The result: bashing on the vendor because "yes, you met the requirements but you didn't give me what I want..."
I have seen a few vendors submit two-tier proposals. One is the quick and dirty bid, the other the doctinaire bid. If a vendor honestly explains the differences, the buyer can make an intelligent call.
-- Slashdot: When Public Access TV Says "No"
Never Compromise Quality. It's not worth it in the long run.
If management and marketing expect you to shit code out your ass on demand, then make them give you some toilet paper in the form of a signed document saying you will not be held responsible for any stench resulting from the project.
And continue to follow the process! If you can't get your code through a review, make someone in charge sign a waiver and keep several copies of it on file.
Also write up some release notes listing all known and potential bugs, and make everyone you can find sign it.
And while you're covering your ass, get your resume in order and keep sending it out to companies with a clue. Eventually the tech sector will turn around and you can bail ship.
A Government Is a Body of People, Usually Notably Ungoverned
Quite clearly if you are getting in hot water for the Quick & Dirty solution, then you're doing the wrong thing.
You're also asking the wrong people. You see, this isn't a techy question, this is a business question. You don't get to make this decision, and there is no right answer from any technical point of view. It's entirely up to the business need. Is a prototype that you're going to scrap a completely acceptable solution? Sometimes it is, sometimes it isn't. It depends.
Speaking from a customer view point, a lot of us have been burned by dorks like yourself who think they can win a contract by showing us a prototype and claiming it's the final product. We've bought the bait, paid the money and then wondered why after a year the solution still doesn't work right.
The information super highway is littered with the bodies of such bad deals and they leave a really bad taste in the mouth. So while you might be thinking it get's you the deal right away, the long term impact of your actions is a bad reputation for your company. And word spreads around... You're definition of Success is hardly in the customers best interest, as you apparently are only looking for ways to soak us for cash.
It's up to the PHBs and Marketroids who you apparently disdain to be making these decisions because they are the ones who understand the customers position, not you.
People used to have time to do projects correctly, but when one person takes the quick & dirty approach, upper management starts expecting the full process to take the same amount of time as the shortcut. So, eventually, no one does anything completely right and they cut corners everywhere or else they'll lose their job.
Subsequently, the marketing people start making promises we can't keep and we're constantly working 60 hour weeks to try and keep up to the point where we start burning out and product schedules slip. We start losing customers, then revenue. So the layoffs begin because of lower profits.
So in the end, there's just one guy doing a half-assed job as fast as possible while the rest of us are either in mental institutions or unemployed.
From that, I would say do the quick & dirty approach if you want to keep your job.
..and invented docs afterward.
YOU HAVE A FUTURE IN THIS INDUSTRY.
Best Wishes,
Bill Gates
I've been in very similar situations and discovered the solution is to tell the suits/marketeers up front in WRITING of the cost/benefit differences of the two approaches, then let them decide.
Later when they complain about the shoddy work of the quick, dirty and cheap solution they chose, wave the email in front of them.
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
Alternatively, you (plural) could open a Portland, Oregon office, and hire a lot of good talent for cheap.
Finding God in a Dog
Do you even realise how incompetent and internally inconsistent your words are? Because you do know the syntax and lexical scope of pragmata, as well as the semantics of use and no keywords, right? *sigh*
Karma: Positive (probably because of superiour intellect)
I primarily work in an Operations role, but spent some time with Dot Com Bombs and larger companies, both as an admin and a software developer/maintainer. In the last 12 years, I've learned a few things.
First, users don't know what they want, by and large. It's a gross generalization, but it tends to be true (IMHO and experience). They have an idea, but as soon as they see something, they want it a little different. Hence all the custom software.
Are businesses all that different? Not really, but it seems each manager/owner/CEO wants things a little different. Maybe it gives them an advantage, maybe not, but they want it and are willing to pay for it (to a point).
That being said (and you must keep that in mind as a developer). They want results quickly and cheaply. But quickly more than cheaply in general. It doesn't matter if it isn't the best solution, or the most elegant, or even the fastest. "I want it now, Daddy" (insert best Willy Wonka movie imitation).
I've worked on large, managed, planned, projects and worked on impromptu, "hey that would be cool" projects. Some have failed, some succeeded, but there wasn't a correlation between the failure and success (from a business standpoint) and the method of coding/developing.
In fact, I've come to favor the quick and dirty method kind of mixed with XP. Do it quickly, do small changes and GET FEEDBACK immediately. If you've gotten some experience, you can coddle something together as a proof of concept, but something that still is coded well and is maintainable. Keep in mind, often you're doing the maintenence, so hopefully you learn over time that functions are better than cut and paste, classes simplify future development, etc.
Also, you will maintain it. Or extend it. Turn bugs into features (hopefully not vice versa) and keep users happy by showing progress. And responding to their needs and whims. That's what we get paid for. Want to write elegant, efficient, perfect code, head over to SoundForge and help out.
You've got to walk the line between writing good code and GETTING THINGS DONE. Results count. Not elegance.
I understand this doesn't work for shrink wrap or large deployment software, which can't really work with a rapid development model (more gross generalities), but it doesn't seem like that is what the poster was working on.
Clearing major changes with your cowworkers is generally a good thing.
Yeah, we've got a couple of large people working here too.
"There are people who do not love their fellow human being, and I _hate_ people like that!" - Tom Lehrer
Granted, most implementations I've seen have been either quick, dirty & unmaintainable vs. correct, proper & maintainable, however it doesn't need to be that way.
;>)
There are many simple, easily understandable architectural decisions that are quick to implement, and open your system up for easy extensions and improvements.
1. Establish an object heirarcy (OO only of course). It doesn't have to be exactly right, it just has to be there. You can then easily add common methods to superclasses & all subclasses will have access to them.
2. Separate presentation from data.
3. Separate interface from implementation.
4. Small methods with single functions (see 3).
5. Function lockdown; force coders to perform operations in one way only (retrieving a record, generating an error etc, again, see 3.)
There are certainly more things one could do, however you're now overlapping with 'complete & proper'. These simple steps will not only give you a system that's quick to implement, but they will give you a system that is completely flexible to future changes & additions.
On second thot, don't bother. I'm making major $$$$ from incompetents that don't appreciate this
The problem is all engineers have provided a Q&D solution at least one. Time? Money? Other constraints? I can't tell, but it sometimes seems people prefer things tat "work quite well" to things that actually work they way they're meant to work. Yesterday, /. pointed out the availability of Edsger W. Dijkstra's manuscripts. Some people are still inspired by his pursue of code elegance, well-though, goal-defined programming and getting it right from the beginning.
Seriously, most software developers live from maintenance contracts (a.k.a. fixing the shit I developed for you) rather than selling a fully-functional, fully-tested 1.0 version.
We should all try to get it right the first time. This is particularily true for engineers (not programmers); The use of well-tested and mathematically solid algorithms while coding a well-designed system (which followed a thorough analysis) should be our "de facto" way of life... not just patching things we wrote out in a hurry.
Commander: "We have a hopeless situation... We're all going to die!!!! Engineer, HELP!"
Engineer: "We can make it work, but it won't be pretty!"
E: (to other engineers) "What if we crossconnect the plasma conduit directly into the warp drive, then tie it to the transporter via the deflector dish?"
C: "Will that work?"
E2: [With Sarcasm]"Once... maybe"
C: "Good enough. Make it so"
E: "Alright, but if anyone asks, this was your idea"
E: "I can't believe I'm doing this"
C: "What's that?"
E: "Oh, nothing..., just checking my dignity at the space dock"
E2: "I can't believe you suggested that. I'm embarassed to be on your team."
E: "At least we'll still have a team to be on..."
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.
A true "master" will produce code that succinctly solves the problem - maybe something like replacing 10K+ LOC with about 100 or so. And those 100 or so will be well-documented and so damn simple and maintainable that everyone reading it will say "Damn, why didn't I think of that solution."
Something obtuse, obscure, and hard to understand is the mark of a curmudgeon, not a master.
Reward something, and you will get more of it.
corollary:
Penalize something and you will get less of it.
It sounds obvious, but that is what most companies suffer from. It sounds like they actually reward you for producing the good looking façade with bailing wire and duct-tape beneath. They say they don't like the "not following procedure". But what happens? Nothing? Next time do they say "do it right" or "do it now"?
Do you sign off on the release, or is that a PHB function? Is it YOUR boss' function? Is the "heat" for not doing it right coming from somewhere else? Did you clearly state the quality when you made it available or it was taken from you for release?
Screens saying Alpha Version when started might help. What I can suggest is that you ask the people giving you heat for not following procedure require such a screen until THEY sign off on it which THEY should only do when all the procedures are followed and all the loose ends are tied up.
If they don't have the authority to prevent release, or don't want to exercise it, ignore them. They are merely acting as a conscience in a company that doesn't want one.
( author likely wasn't unaware of this, but.. )
The author may want to look up the history of the term 'Final Solution' (Google will do), just so you know if you really want to use it in the future - especially when saying the method would be quick and dirty.
--
To get back on topic, I use a little of both whichever is the most appropriate method which doesn't cause too much trouble down the road.
For example, the proper way for a windows-run application I wrote to check for FTP uploads would be to enable the FTP daemon's ODBC support and hooking into that.
The quick and dirty way instead is to check the upload directory contents on what would could be called a cron job.
Turns out the quick and dirty method is actually the most stable, with the fastest response times. Even though technically it's far from proper (coding) procedure.
On another job, documentation (yes, not quite coding, but it applies), I could simply run a code interrogator and present the clients with the results from that. It has all the info they should need.
Instead, I'm making an extremely detailed report which can be presented well both on monitor and print (thanks CSS).
In the first case, the speed and reliability was much appreciated.
In the second case, doing things properly is far more appreciated.
So it really depends on the job and what the consequences are/would be.
You should read a little about theory of constraints, in particular conflict resolution diagrams, as it would help you to find solutions for your problem.
The main question is one of: Profit now Vs. Profit later. This conflict (or some would say apparent conflict) is what you as an engineer need to explain to management, this is the tradeoff that is being made, and in order for the conflict to disolve you need to find solutions that satisfy both, or at least make the trade-off knowingly.
Put the developer on a plane to see the customer, and have the dolt who broke the product apologize. Do it all at company expense - because you'll never have to do it again, so what's $2000?
If the programmer quits over doing something like this he wasn't worth keeping - he doesn't have the backbone to admit he fucked up. And if he does have the backbone, he will have learned a valuable lesson.
The answer is simply that there needs to be constant communication between you and the people making the business decisions. Inform them at the beginning, of a project what following proper processes will do for the project, for the code and for the business.
Be honest about how much more work it is for you to do one thing or the other, and what the benefits are. As issues come up through the project, be honest about the impacts, and what differences there are between the quick fix and the proper fix. When the project is done, do a post-mortem and analyse what could have been done differently.
Let business make the important business decisions, but inform them of the impacts of their choises. Ultimately the code you are writing in this case belongs to the company you work for. The company needs to make the right decisions, and the company should be responsible if the decisions that were made resulted in proper process not being followed, not you. You job is to inform and deliver.
You'll find after a couple of projects with this approach, everyone will begin to understand the issues involved, and the right decisions will tend to get made mor often.
Tell the PHB that the action was a temporary firefight measure and now the real solution needs to be put in place. If the quick fix was a turd, then throw it out and do it properly - don't go polish the turd
Unfortunately I think too many PHBs are overcommitting and too many engineers are shit scared of losing their jobs ("You can't do that in a 40 hour week? No sweat that Indian outsourcing place will do it in one 60 hour week."). This means that likely you don't get a chance to catch up and straighten out the mess. Put out one fire, move to the next.......
You have to be careful that you don't end up creating more problems than you solve.
Engineering is the art of compromise.
Q&D worked for the most successful company in the world, Microsoft, so apparently it's a good idea. Just make sure about your license agreement: "You can't hurt us, we can hurt you" and "All your money are belong to us", that's about all Microsoft has there and it seems sufficient.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
It's a business decision - profit some now with a crappy product or lose market share hoping to make profit up later with a better product.
If he's not a corporate executive he has no right to make that decision - that's what the boss is supposed to do.
Just be damn sure he documents the decision-making process...
I've got two answers. The first (even though it sounds like a stupid cliche, of the sort that Dilbert's PHB is wont to mutter) is: "work smarter, not harder". See if you can't do the Correct & Proper thing, in the same sort of compressed timeframe that you were afraid was forcing you into the Quick & Dirty thing. You're a code jockey, right, with the latest high-productivity development tools? So show us what you can do! Why should Correct & Proper have to take so long?
Yeah, I know, sometimes it does, especially if you're not so much writing brand-new code, as figuring out and trying to fix a bunch of old, broken, legacy code. So the second answer is: when you're forced by schedule pressure to take a Quick & Dirty shortcut, that you're probably gonna have to go back and do right later, at least make sure it will be possible to do it right later!
Far, far too many Quick & Dirty shortcuts end up being impossible to get rid of, because they have far-ranging repercussions. Perhaps the quick&dirtiness is exposed via an API, in such a way that fixing it would require rewriting all callers. Perhaps the quick&dirtiness shows up in a data file format, meaning that you can't fix it without invalidating (or having to convert) all the existing data files. Etcetera.
So when you find yourself doing the Quick & Dirty thing, take some time to think about the Correct & Proper thing you'd rather be doing. (You've already done some of this, or else you wouldn't be asking the question in the first place.) Figure out how the Correct & Proper thing would interact with the rest of the system, and make sure that your Quick & Dirty shortcut either interacts the same way, or that there will be a graceful migration path available.
The only thing worse than an ugly, Quick & Dirty shortcut is an ugly, Quick & Dirty shortcut that can't be fixed later, no matter what, even if you do find yourself with the resources and the motivation to fix it, because it's become ossified in some way. (Think 8.3 filenames for but one example.)
Microsoft, for all their reputation as purveyor of buggy code, has done some doozies of redesigns that saw them win in some major areas.
Netscape got a two year head start on MS, but MS's rewrite of IE for version 4 - with its real programmable hierarchy, pretty much left any NS offering in the dust until gecko came out years later.
Windows NT had a much better guts than did OS/2, and took much longer to get to fruition. Even Windows 95, for all of its goofiness, was a carefully calculated and lengthy development. W95 offered a real transition from both DOS and 16 bit windows to at least some kind of 32 bit OS and without really too much aggravation.
The whole
Access was a -long- development, but it proved much more successful in killing off competitive desktop database competitors then did the acquired FoxPro.
Bottom line is that hacks only take you so far, and eventually, you will lose by doing them.
This is my sig.
"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
I have a coworker who is famous (infamous amongst the software team) for proclaiming "I get things done fast". He gets work cleared from his to do list very quickly, and management thinks he's a genius for it. He's even been given a raise.
From the rest of the team's perspective, he gets things done the excruciatingly slow way. First, he gets the job "finished". Then, one of us has to fix it so it actually works, after having wasted an hour in debate with him over the crapiness of his work. His ego, kindly boosted out of control by management, will not allow him to accept the fact that his work is unusable. We could get things done twice as fast if it weren't for him taking the "quick 'n dirty" way.
But as to which approach is "right" - it's a matter of perspective. From his perspective, he is clearly doing the right thing as he completes his work list quickly and gets glory and money. From management's perspective he is doing the right thing - he is performing exceptionally well according to the only measures of performance they are willing to deal with. From the team's perspective he is a nuisance that costs the company in wasted time and money, and makes our jobs more stressful. We try to stop him from getting his hands on anything too critical, but it's hard for us to control.
The best approach can depend on where you stand.
"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.
Development costs become infinite once you reach Correct and Proper.
1) Quick and Dirty = the fastest way to get the program functioning to meet immediate expectations.
2) Correct and Proper = the carefully planned, perfectly engineered, flexible, and robust solution that will meet today's requirements and accomodate all of tomorrow's unforeseen circumstances.
Item (1) exists, item (2) does not.
We can only approach Correct and Proper, but never actually achieve it. Each step closer to Correct and Proper requires qreater and greater development time.
You just have to decide how much time and energy you can expend on a given problem when you shoot for it. Get as close to correct and proper as you can while staying in budget (time and cost). Just make sure everyone involved understands the limitations imposed by the budget.
Its always a balance.
If the customer values getting the product early and sacraficing quality, and are willing to pay for it...LET THEM. They will pay for it in support later (assuming your contracts don't warrant your products will be free from defects). If the customer values quality over time and price, they will want you to take the time. The bottom line, the "Correct way" is what the customer is willing to pay for.
"Iraq has weapons of mass destruction."
And from the looks of it, they usd them on themselves.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
"Quick n Dirty" is my middle name.
I'm thinking of getting it tattooed over my back in gangsta script.
west-syyyde
There are some odd things afoot now, in the Villa Straylight.
it was in a book review for a book about programming techniques.. "Make it work today, optimize it tommorrow" as soon as ur done with your project, sumbit the dirty solution and later on optimize it properly
For The Best Jazz/Hip-hop fusion > COlD DUCK
is to follow your principles into the street where you will be sleeping from then on.
-pyrrho
It takes a programmer to come up with a binary solution. ;-)
The question between Q&D en Clean and Proper made me think how I judge the projects I get offered.
This is in short the steps I usually take:
1. Real life truth: There are no customers who actually want to foot the bill for doing everything clean and proper.
2. Question: What would actually be required to do this job according to:
a) Technical requirements
b) Professional ethics (No keyboard errors in typing this)
c) Maintainability (Commercial sideline: and who is going to profit from this?)
d) When is the stuff I didn't do going to bite me in the ass.
3. (Scary part) Communication: What are the customers expectations of the work delivered?
4. Given a reasonable assumption of clean and proper (I usually use CMM level 3) which things can I scratch from my mental checklist with the lowest risk given points 1 to 3?
5. (Scary part deux) negotiate the difference.
6. Choose: you are either a carpenter or a guy who can nail two pieces of wood together (see 2d).
Ratl.
Quick and dirty makes a very nice excuse. Just do a half-assed job, and if you ever get called up on it, just say a few magic words: "I needed to get it done fast because of the schedule". There will be no debate about whether your actions cost the company or not, no question as to whether there really was a deadline or any schedule pressure, and under no circumstances will any logic be applied.
If you have some control over the amount of acceptable general "looseness" in code quality for a project, determine in advance a good position on the "quick 'n dirty" to "correct and proper" spectrum that meets your needs in terms of quality and timeliness. Then move a long way over towards the "correct and proper" end, to account for the fact that people are far more lazy and ignorant than you expect, and will use the "quick 'n dirty" excuse whenever they're given half a chance.
If you have built good autoupdating tools (or are writing a web application) you can do quick and dirty with little impact on the user. If you *should* is is an endless argument (the XP crowd vs the Waterfall). My preference is for XP style, and so far it has allowed a company I'm part owner of to out maneuver a company that has (conservatively) 10,000 times the cash and resources that we have. They keep asking "how do you program so much so quickly". A handfull of *skilled* (don't try XP with newbies) designer/programmers will outperform a room full of lackies every time.
Leave you unskilled programmers to the task of "refining" code, and your talent to "building out" the code. The unskilled programmers slowly learn from the techniques they are working with, and join your design team over time. Thus quick and dirty evolves into "correct" code.
Sig under construction since 1998.
I almost *always* opt to do it right the first time, regardless of the consequences. If you don't, nobody is going to give you the time to redo it correctly. And they're going to ream you for not doing it right the first time even though they didn't want to give you the time and resources to do it in the first place. PHBs are, by definition, incapable of understanding the simple mathematics of the situation: pay a little now, or pay a lot more later. I do my best to quote "quick and dirty" development times that are sufficient for me to actually do it right, and I usually get away with it. Those instances where I can't get the time, I either purposefully underquote the time estimate, knowing full well the project's going to slip, or work overtime to do it right in "Q&D time". I don't mind being underhanded about it. I'd rather do the job right or not at all than do it crappy, and often underhanded tactics are the only way to deal with PHBs.
One example of a Quick and dirty commercial product is Crystal Reports (I'm currently on v8.5).
It has gone through several version numbers but it still behaves like the version I first used 4 years ago.
This is evident on error handling. One example is when connecting to an Oracle db and letting the connection to timeout(i.e leaving Crystal open all night). Crystal doesn't catch this and simply explodes with an exception window. You wonder how difficult would it be to check for a 'ORA' type error code before trying to render a report.
Other cludges include the extensive use of formula fields for handling special conditions in the result set.
for many, the only motive for anything they do is monIE, so the 'organization' of things, is around that, period.
as soon as you remove the mammon motive, things clear up considerabully.
there's a 'cost' to everything. be it time/monIE/energy, etc...
lookout bullow, the daze of the Godless phonIE payper liesense stock markup FraUDs/georgewellian corepirate nazis (see also: SourceForgerIE(tm)), is WANing into coolapps.
consult with/trust yOUR creator. vote with yOUR wallet. that's the spirit.
the ?pr?/marketeering budget for promoting good/the right thing, is $0.00. it's ALL volunteer work. however, the reward/'payoff' is immesurable in yOUR terms of measure.
as for the continuing exploding infant problem,..., you know something's going to happen there.
as for va lairIE's excessive use of his pateNTdead PostBlock(tm) devise, what a fauxking whoredoggIE heis.
How the heck is this offtopic? Just coz it's not answering in one easily understood sentence doesn't mean it's not answering.
this is so stupid.
by definition, Correct & Proper is always the way to go.
Thats what "Correct & Proper" means.
Quick & Dirty == HACK
are you just trying to get a rise out of people, or what??
grow a brain.
When you are required to do a quick and dirty implementation do the following:
a) Embed a show stopper bug that is very hard to find.
b) Make a big deal about how difficult the bug is to find and how hard you are working to solve it.
c) Keep telling everyone that the bug will be fixed very soon. Keep their hopes up.
d) When the CEO comes by to find out if he can tell the customer that the product will be ready on time - you tell him that you have found a hardware/design/requirement bug and you have implemented a "magical" workaround that will not only fix the product but make it better.
e) Keep reminding everyone what a great programmer you are and how little credit you get for solving the really tough problems. Make a special effort to remind your bosses and the CEO of this when it get close to your review date.
If you master these simple techniques you will soon be promoted to manager... Where a whole other set of "Techniques for Success" will need to be learned.
In my 14+ years in the software industry, what I've found out is that you can have a good balance of Quick and Dirty vs Too much Process.
Typically managers want to make monkeys out of you... and that drains the passion out of development. What managers want is to give a bunch of UML and say go out and do this, and dont think! This is the begining of creating "replaceble parts" out of engineers. I despise those environments and thrive in environments where I dont get pigon holed into a corner to do a tiny little task without much thinking. The heavily process based places got very little out of me, and the ones that gave me the freedom reaped lot more out of me.
> had fielded no fewer than 5 complaints from your peers
1. "He keeps looking at me."
2. Surfing too much
3. Trying to hack past surfing porn filter
4. "He keeps looking at my feet."
5. I keep having to fix his bugs.
"Has [being a kidnapped teenage girl, raped repeatedly for months] changed you?" - Katie Couric to Elizabeth Smart
I know MS-DOS started out as QDOS. Who made CPOS?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
If you are building a mission critical system that will kill people or create irreversible harm to a party if the system fails you had better do the well documented strict process control. If it does fail you will get sued or have a massive recall on your hands. Have long email records and always let management make the hard choices. But be upfront with management. Don't be a famous engineer. ( avoid space shuttle o rings or foam impacts )
On the other hand, web development is not mission critical in most cases. And it really depends possibly how critical the information and security etc.. ) I'd say you need a minimal process to operate out of. Initially it will slow people down ( since nearly all web developers are hackers and will complain about any process ) but once they get use to it things can move quickly. Particulary, a team effort because everyone has to be on the same page. That is, source control, installation, and some minor QA. Do it right from the beginning. Have someone other than the programmer check the core functionality. Rough edges that are not core features can be chisseled out later. I'd also say if its not mission critical you probably don't need to sign a paper at every step. But atleast have the minimal process.
Also, just spending a little time in the beginning to hammer out a design will save you tons of time and can possibly prevent huge rewrites later on.
Typically, I'll see companies play it real loose in the beginning. They will mess up. The customers will be pissed and heads will roll. Then they goto the complete extreme with too much process. Then they might loosen up a little and we'll be in the middle of the extremes. But if you start out in the middle from the very beginning you can avoid all this.
Also, having no process is a real pain if a company grows. Because the newbies will not be able to integrate well with the product and there probably is no source control or installer.
I'd say the folks at Netscape started the release the alpha and patch it later culture.
Just my 2 cents...
One thing that always kept me from taking time to do things the right way is that it takes a long time to figure out where to start. Doing it right actually does not take a super long time when you know exactly what you need to do.
Doing things the right way myself is one thing. But getting other people on the team to do it the right way take can a LOT of explaining, and we end up arguing little points that are a total waste of time.
This project on freshmeat a few days back. It's HTML templates for test plans, use cases, project risks, etc. That could help do things the right way a lot quicker.
but _always_ time to do it over.
Exceeding the recommended torque is not recommended.
I work for a very large company who shall go unnamed. We have process for everything, and typically, when it comes to my department, the only thing it succeeds in is slowing up the works. Technically I'm supposed to have as many as a dozen different people sign off on changes to a very complex business-rule core that I maintain, along with one other guy. It's considered one of the black arts of the company, and as such there are only 4, perhaps 5 people who understand how the darn thing actually gets its work done. However, it's the basis for almost every significant device we use. We're not a software house, we're in another industry entirely, but have a large IT shop to support it. The problem is that everybody signing off on my stuff doesn't have a clue how it works or that it works correctly. Half the time I have to invent new business rules for cases that the marketing and even operating people never considered when dreaming up new services.
We have another piece of the IT shop that is chronically behind. They're never caught up, and they always have to put stuff off because it missed a "critical" (as defined by the corporate process) meeting or review, or they don't think they have the time to do it. They whine a lot, their developers are mostly mindless droids that write the code their spec tells them to, any changes throw them into a complete panic, even if it doesn't affect them, etc.
As with all things, your approach should depend on your situation. I tend to play fast and loose with the process when I know the business really needs something done, but nobody's got the balls to put it on their corporate timelines and risk looking bad for the sake of internal politics (this is on a timescale of 18 months, yes months, to market). Often this is to compensate for the aforementioned group that can't get their asses in gear and get stuff done. I've put in many 18 hour days with my coworkers to pull of amazing stuff that nobody will ever know about - just because we slipped in the solution unannounced and everything works fine in the end. If we hadn't, opportunities would have been missed, the ninnies over on the other side would have fallen further behind, etc.
On the other hand, stupid projects that I want to see die horribly because I think they're a bad idea? Run 'em through the full process, making sure to follow each and every exacting step. Usually they die slow and painful deaths.
It's simple spend the money on the process now or spend it later. Companies have processes because they reduce the risks. The risk is if you get hit by a bus tommorrow all your projects may die with you. Because you did not follow the standard process your replacement may take twice as long getting up to speed where you left off. You are paid to follow the process and devliver a product.
Now if the process is too inflexable for your business maybe it's time to revise the process or implement tools to make the process more efficient.
Process and policies may be a pain in the ass or seem like a waste of time/money but they do serve a purpose. They let everyone know what the rules of the game are.
When I need to step outside of a process I tell my boss that this product/project will be late because of a breakdown in the process and I get them to waive the requirement...never hurts to follow up with email.
Marketeers like to think of themselves as visionaries shaping a new world. So while your half way through the current project they are dreaming up the next great thing. They may need to be dragged back to reality and the process should help you do that. A good process should keep everyones eye on the ball...the same ball.
My random thoughts on the subject.
People who bite the hand that feeds them usually lick the boot that kicks them
It seems to maintain that there is only one type of freedom. Anyone who has no medical care wants free medical care even if it's 1954 level medicine. Money controls what people do. If you don't have money then you can't do certain things. I go, if only we controlled people my way people would have different freedoms. Now who wants to be free to go to an amusement park with 1954 level rides?
Where I work, we do a Q&D solution for trade shows, etc., but when it inevitably doesn't do everything marketing and/or the customers want, we use that time to do it properly. Eventually, we do end up with some good designs. I'm also fortunate enough to have an employer who believes me when I tell them "this is how much time I need", although that often pisses them off because it's always much longer than they'd assumed before they asked me.
No matter how quick and dirty it is, you can always keep in mind where your code should separate so you can refactor them piecemeal later. The long, slow development process should allow for refactoring anyway, so Q&D should be the normal programming method while you are prototyping, and then you refactor your code into nice, clean, re-visitable, re-usable modules. It's the best of both worlds. Just don't refactor more than you need to; no code ever really lives forever. Make it clean enough to acheive your goals but don't go overboard.
Technically Mallrats is a prequil to Clerks, Julie Dwyer died in the pool the night before Mallrats takes place and Randal and Dante went to her funeral the day after that. There's also a timeline of events in the booklet in the Chasign Amy DVD.
"Sic Semper Tyrannosaurus Rex."
1) do it quick and dirty to save the corporate cahones 2) get promoted before all the inelegant bugs surface 3) let the next poor schmoo explain to the PHB (now you) why the miracle system is no longer working
Two wrongs don't make a right, but three lefts do.
But there's no guarrantee that the meticulously developed code will be more agile at responding to these unforseen inputs than the dirty code. Remember, the meticulous code was designed around a specific requirement, and now the requirement changed. So the question is, when you decomposed the initial problem were you smart and lucky enough to properly identify the fault lines and build in the right kind of flexibility?
My approach has been to gradually assemble a reliable work environment with mature infrastructure over time but to build the current software with what is the best I can do at the time. For example, I am current creating Enterprise applications for a corporation and we are slowly migrating to Java and away from Perl and VB. And while nobody on the team has a great deal of experience with Java, several of us are learning rapidly and making decisions which will help us write more robust software in the near future. The first few applications ported over to Java were not the cleanest, but we learned from our mistakes and kept building.
And that should be your biggest lesson in IT or any field. Learn from your mistakes and develop solutions that help you do better in the future.
Another point I would make is to start with a good base of technology. I am finding that Java is a great base lately in large part to the support from the Apache Foundation and the associated Jakarta, Ant and XML projects. Coming from a Perl background I can see a big difference in the available Java packages that are extremely easy to integrate for a complete solution versus the Perl archive of modules which are sometimes incomplete or poorly tested.
My overriding rule for IT development is use what works, and actively avoid anything that is not proven.
Brennan Stehling - http://brennan.offwhite.net/blog/
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
We probably have the same employer. My employer has chosen a very unique end-run around customer service: automation to reduce headcount. These are the rocket scientists responsible for making you talk to a computer that might (or might not) create a trouble ticket that might (or might not) get worked on by a human being.
When a member of the top-tier of management (aka CTO) decides that this is The Right Thing(tm) and none of his subordinates have the balls to point out that he's full of shit...the shitty environment trickles down. It becomes a war between the coders (who want to justify their jobs) against the users (who actually do the work utilizing the tools provided by the coders).
I don't foresee an end to this cyclic problem until people wake up from their apathy and start providing feedback to the companies that piss them off.
Very odd thing, but down to earth one. This how almost consulting firms works. They need to show the lowest price to win the contract. So, the do it Q&D and almost working properly. Then, as bugs and problems arise, the customer has very few choices than paying them again to fix it and do it right.
And if the customer is not happy, just let him know he is the very first person responsible for all this fiasco (for him).
This is very frustrating for those of us who like to do a good job and do things right. But be realistic, nobody is willing to pay for something he doesn't see an immediate advantage for. So, even customers want Q&D jobs rather than right and clean ones if it doesn't fit the bill (lowest price).
Achille Talon
Hop!
If it means borrowing some SCO code, perhaps you should do it nice and proper.
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.
If you can't follow your process there's something wrong with it. Seriously - it doesn't fit your needs. You should look around for a process that will work for you and give you decent results in the time frames you have to work in. The Extreme Programming methodologies come to mind. I've always found that I can get a Q&D prototype up and running quickly. If I've done my architecture correctly up front and have my APIs set up right I can go back later and upgrade modules on a piece-by-piece basis without having to chuck EVERYTHING. Once you have something working it's a lot easier to get junior engineers to make improvements.
I work for a client who calculates all of our time in 15 minute increments, and will spend 15 minutes of his own time to cut down 1/2 an hour of ours. Everything done for him is Q&D and there is nothing we can do or say to convince him otherwise.
We've explained how the lack of documentation, decently verified backups, backup systems, etc...will eventually shut down his entire multi-million dollar online business.
Nothing is more soul-crushing for a geek.
Here's my criteria regarding development:
Elegance
Amount of work to complete
Simplicity
Redundancy
Extensibility
I find my self working on projects that I have no expectation of future maintenance. Now, for some that would mean that they can do a simple hack and not have to worry about it. For me, it's exactly the opposite. If I'm not going to be maintaining the code in the future, I try to make it follow the 5 criteria above. The lesser amount of questions that someone has to track me down to ask, the better.
With that in mind, here's my explanation of my criteria:
Elegance. This is a subjective criteria. This is a measure of how much the design or code bristles against me. I can look at something and decide if it's elegant, or not. It really has a lot to do with how generic the code is to the application. I prefer designs that are reusable and not highly specialized.
Lazy factor. This has 2 sides, how lazy I am, or how much MORE work it will cause for me in the future. Often these Q&D solutions merely mean more work to make it right in the future. Rather than take the Q&D route, I like to put the effort in up front and be done with it. I am confronted regularly by this.
Simplicity. This really plays towards the work and elegance. The simpler a design, often the more powerful and generic it is. You're not done until there is nothing left to take away before it doesn't work. Simple is easy to understand and maintain. It is also easier to reuse.
Redundancy. How much of the work are you repeating from project to project? Wouldn't it be better if you could design a more generic, simpler system that can be reused for multiple purposes? If you and another developer are duplicating effort, that's a waste. This also plays into code quality quite heavily. If you end up duplicating efforts, you often end up writing the code differently enough that it doesn't easily get fixed, or it introduces a bug. Building generic underpinnings that have cosmetic changes are my preferred method of work.
Extensibility. This is the core of generifying. Code shouldn't be tied to one function or purpose. Look at everything as an opportunity to make it as generic as a library. This way, when management asks for new products, you can reuse the core of another project and simply change the cosmetic features.
All of these points play into Elegance. If you can integrate all of these into a project, you are often rewarded with elegance. Others will recognize it and be more willing to trust your judgement and code. It's important that the sysadmins, who will be maintaining the running of your code, trust you and have confidence in you.
Neither QD or CP are good solutions. Somewhere in the middle is where Engineering and Marketing negotiate to get something out the door that works and is reasonably sustainable. This is where good management comes in.
If Engineers ran the business, product would never ever ship. Correct and Proper plans make the assumption that we can plan for the future 100% accurately. I don't know how many projects I've been on where some zealot engineer claims that we have to redesign everything because it sucks, goes and redesigns and the same guys comes back 6 months later saying the same thing.
If Marketers get the upper hand they end up promising products that god himself could not build.
You must invest more man-hours. Vertically, not horizontally. Add more programmers and manage them well. Then you for example code the quick-n-dirty stuff yourself and your underlings clean up after you as you move on.
Jag pratar lite svenska.
I worked in a software development group at a rather large corporation using .NET where the development mantra was "Ship It ASAP!" for the last two years. Such a mindset didn't allow for any true functional specs to be written, features were added/removed during development on an ad-hoc basis (then the UI spec would be updated to reflect this). I complained about the lack of functional specs in the beginning of May and was laid-off at the end of June. I was told it was for "Economic Reasons" but I knew otherwise. In hindsight, I probably should've just kept my mouth shut (I'm young and still learning) because from what I understand that group got the funding it did simply because it delivered despite the lack of process. Other groups seemed to be stuck in a rut simply because they were trying so hard to get things done the "right" way that they haven't delievered anything in a timely manner.
:0)
I just figured that I'd share my economically painful lesson. Cheers.
I once told our development team that I was going to ease up a little bit. The software no longer had to be Perfect; I was now willing to accept Excellent instead.
Never underestimate the power of Good Enough.
-Mark
A good post...
but you may only have two for any given project.
You can have Cheap labor and a Fast timeline, but quality will not be Good.
You can have a Fast timeline and Good quality, but that is not Cheap.
You can have Good quality and Cheap labor, but that is not Fast.
The true answer lies in the question:
"Do I have to maintain this project?"
The sad part is that most corporations are looking for the correct solution, but they want it at the quick and dirty pace. Where I work, everything goes fine as long as you do it quick and dirty and don't mention it to anyone. But as soon as it is found out you are doing it the quick and dirty way, management steps in and comes down hard. They don't really care that you were doing it quick and dirty, they are annoyed because someone found out about it. So after you get berated for doing things the quick and dirty way, you have to do things the correct way, but then you get berated again for not being as productive as before. Explainations fall on deaf ears or are called excuses. So it's back to the ole quick and dirty and the cycle starts again.
Smeghead every day of the week.
softwarereality.com
Please code in referenced sites as hot links properly. During these coding threads, some of us are so excited that we're reading with one hand, so it becomes extremely difficult to manually cut and paste the link into Mozilla.
This may have already been suggested, but a good approach in these situations, assuming the resources are available, is to do it both ways in parallel - one team does quick-n-dirty and the other does prim-n-proper. This way, you're quick to market but also have a head start on release 2 which replaces release 1 when ready.
My past two jobs required quick and dirty programming. Start coding on day one, or get written up. Any analysis and design is rejected and programs got written by the seat of our pants. They wanted complete life cycle in days or weeks, not months, and that included QA testing.
I consider this "Fast Food" programming, fast development but harmful and full of flaws.
PHBs and managers only seem to watch the time it takes to write a program and not the quality of the program. Anyone who takes the time to do any analysis and design and write flow charts and object charts get terminated or put on probation until they can do things the way we were not taught in college.
I was a "Legacy App Developer" two jobs ago in a law firm that let 30 IT people go in four years out of an IT staff of 35. Being in the "legacy" group, meant that I got the programs that ex-coworkers had worked on and that were incomplete, undocumented, missing flowcharts and other design documentation, and full of more bugs than an Ant Farm or a Microsoft Beta Operating System. I had to work with spaghetti code, it was VB so it contained a lot of GOTOs, they didn't follow our naming convention and used i, x, y, z, s, c, and other short names which I had to rename to make more sense. All in all, working with this code to put it up to standards took longer than I thought. But I made it more reliable, faster, and documented my work as I went on looking at it. As a result, the managers took a look at it and saw that thanks to my changes now anyone could work on the code, and since programmers are a dime a dozen now they could fire me and then hire someone for a fraction of my cost to work on them. Last I checked they fired my replacement and are looking to hire someone else. He took over a year trying to convert all the ASP and VB apps to Dotnet and couldn't.
But anyway if we don't do quick and dirty programming, they will outsource it to people in other countries either by H1B Visa workers, or out of country sweatshops.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Sometimes quick and dirty is right for the company, and sometimes well engineered is right for the company. On the one hand, products that miss the market are likely to result in a company that goes out of business. On the other, products that get to market but are so shitty people can't use them won't win market share, unless they are the only game in town, or there is some sort of major contractual lock-in. Ultimately, quality is an engineering tradeoff factor, along with development time, and all those other tadeoff axes (gosh, I forgot my project management 101 stuff - go read "Rapid Development" for a decent primer on this - it's a great book, you won't regret it even if it is from MS press). The key point is that these are decisions that will affect the business and product engineering side of the company, so don't make them unilaterally and then get shocked when people feel fucked over.
I'm on a contract now where we are documenting the design after the product has been coded and tested successfully, so it CAN be done after the fact. In fact, I would say that it NEEDS to be done... whether or not it is now or later is debatable. But in the interest of the complete lifecycle of the software, you've got to follow processes and procedures.
I'm assuming that you are not a CMMI certified outfit, because otherwise you wouldn't even be asking the question... the answer would already be decided: Do it the Right Way.
I guess what I'm saying is that if management wants it quick and dirty, then give it to them, but make sure you impress on them the fact that you need to budget time and money to document the software after your delivery.
- 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
Well I don't know what things are like where you're from, but here in the Real World "Correct and Proper" isn't even in the dictionary.
When will mamagement/marketing or any other departments learn to estimate appropriate IT deadlines. To many business decisions are made not knowing their repurcussions on the front line of IT timelines. IT workers get stressed trying to meet ridiculous deadlines, and quality work is never achieved, nor is it a requisite from the managers. It's time to treat IT workers as normal people and give them reasonable deadlines!
"Quick 'n Dirty" == "Correct and Proper"
Funny, yeah, but also a useful approach, if done right.
When I'm faced with "Get it running fast", I try to make sure that I toss in terms like "prototype" and "proof of concept" at every opportunity. Especially when dealing with PHBs or customers.
Then, when they complain about bugs or missing features, I say "Yeah, and here's a list of some others I know about." And I add that I'll be happy to work on improving the prototype into a useful tool.
It helps a lot if you know how to do "prototype" programming. Write the prototype with the idea constantly in mind that you're writing hooks on which to hang all the things that people will want in the future. Plan on extending it. Call small functions that don't seem to do much, but you've realized that a useful program will want a lot of extending there, so you encapsulate it now. And so on.
If you keep hitting them with the idea that you consider the quick-and-dirty version to be just a prototype, they're a lot more likely to be happy with it despite its limitations, and to want to pay you to add all the things that you didn't have time for during the prototype phase.
You can also preempt a lot of criticism by constantly complaining about how it should be done now, but they keep bringing up new things that they want it to do. And when a new feature means you have to radically rewrite something you did earlier, complain about it, but let them know that if they really want it, you're willing to spend the time to make it work right.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
wow :)
From your question I gather your either:
:)
1) Fresh out of college with no practical experience. Are you complaining about the $50k worth of kowledge you just "learned" is useless?
2) A Married/Sports/Party guy with no time to spend exta hours in to make the project happen. You do know that being a programmer is like being an architech only your the supervisor and crew. If your not willing to stay late to make it happen, then you may not be a programmer. Have you ever slept in your office or cube?
3) A VB Warrior who just got burned because your 20+ man hour dialog sucks (user unfriendly).
(Sorry, I just had to throw that in. Current history from one of our VB warriors).
4) A person who writes shoddy code and expects the QA Lab to catch it. If you can't send your binary to the client directly, then you shouldn't be submitting it for testing in the QA Lab.
Thats it from me. No Advice, no speeches, just a sigh.
Enjoy,
It's just the normal noises in here.
Your comments reminded me of a story often told by Intel people.
One exec foolishly asked Craig Berrit about what does he want for product development. Does Berrit wants it to be fast, quality product or on the cheap. Berrit's answer was "yes".
Rumor has it that the exec. was never the same after that question.
It is often hard to strike that balance and explain it to arm chair quarterbacks who unfortunatly reviews your performance and signs your paycheck.
I've written a lot of code. Probably well over a million lines all told, in probably half a dozen different languages (APL, C, C++, Algol, assembler of various flavors, Matlab, Visual Basic, Lisp, who knows what else). Some of it was on contract basis, some as a salaried programmer, some of it as a graduate student, and some of it as a professional scientist.
Every time that I made the choice to cut corners and take a quick-and-dirty solution to a problem, it came back to haunt me. I've lost track of how many times that's happened. However, I still elect that approach at times, because, at times, expediency is more important than correctness. Whenever I knowingly commit such a sin, I *always* document it in the code, and suggest a more rigorous approach in the comments.
When I've taken the time to do things properly, it's given great joy to be able to, say, re-engineer fundamental aspects of an architecture without having to re-write vast tracts of it, or understand quickly and easily what a set of functions are intended to do, or be able to modify years-old code that I haven't looked at since it was initially written. As an example, I've recently been refactoring (to use a chic phrase) code written in the 1995-1999 time frame. Because I took the time to write it well, including documenting it properly, I've saved about 1/2 of the development time on my current project. How? Because I can read my old comments, understand what changes need to be made to integrate the old code into my current suite, and write the new code accordingly. BAM, productivity increases greatly.
Short-term solutions are nearly never the right answer, but if you must, document limitations and any insights into correct solutions. You'll be happy you did when it comes time to correcting the problems later.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
There's 6 bazillion messages already and I'm posting as an Anonymous Coward. Chances are no-one will read this. However, I'll give you a simple answer that will work (and not just for programming).
It comes in two parts.
1) Never do anything that *you* aren't happy with. Always strive to do whatever it takes to make *you* happy with your work.
2) Keep the scope down to the bare minimum so that you aren't wasting your time. Only do what's absolutely necessary. Make sure that other people agree with your assesment of "absolutely necessary" on a regular basis.
Everything else will work out if you keep those two points in mind.
An important accounting/investment principle says "a dollar today is worth more than a dollar tomorrow", and not just regarding inflation. In other words, you discount future earnings compared to today's earnings. In some ways it is "anti-planning" to some extent, and may account for why managers and owners tend not to focus too much on anything further away than about 18 months. It is controversial whether information technology should be immune to Future Discounting rules. But, there is good theory behind the idea. It would be interesting to see somebody debate that IT is immune from this rule.
Table-ized A.I.
They call it off-topic because it's a first post, and it has a lot of content, the beginning of which, at least, doesn't immediately reference the topic of the discussion.
Of course, if they actually read the whole thing (god forbid!), they'd realize that it is on-topic. And I would hope that between the karma bonus and the subscriber bit, they'd realize that I'm not just trolling.
Jouster
Donald Norman in The Design of Everyday Things says that every 20 years or so companies forget their own quality process/methodologies and have to remember/recreate/reinvent them. I say Amen!
That why I find all the present hub-bub over 6-Sigma and TQM etc. so hilarious...we did all that crap at bell labs back in the 1980s! New management decided in the 1990s that quality techniques were "corny" and "too slow" and a new swath of suckers, er-I mean...engineers, came in. Now it's back to the future because these new "teams" built all this crap that didn't work well for customers.
Why do managers refuse to understand the difference between a prototype and a product?! Why are they willing to settle for blame as the default quality process?
I have an idea: Do the correct and proper thing quickly.... (I will mention here that I do not have any commercial developing experience... and I'm certain that everything works differently in the "real world".. but quickly doing the correct and proper thing works like a charm in programming classes).
I will not even entertain the idea of doing a sloppy/quick dirty project. This has meant that on occasion I have had to turn down work because the client thought the estimated time frame was longer than they wanted. But as reputation is everything in this business, I will not compromise. I often tell clients that we follow strict procedures and standards as it is thier best interest, but if they are not interested then they can go find some hack who will gladly do a second rate job and charge a lot less. You will not believe how many have actually came back to me at some stage because "it wasn't working out" with their web developer. And I have looked at the site that has been produced for them by and it is full of errors and sloppy code, and is not flexible enough to add more functionality. Again - try to only take on jobs that you can take pride in knowing that the job is of good standard. The client can't complain if the site does everythig (and more) than even they anticipated.
Of course, when it came time to modify the back end, an appeal was made by staff to refactor the existing code, but the project manager said that unless it could be proved quantitatively that it would save development time to refactor than to just modify the current code, refactoring was out of the question. There's motivation for you. So of course they went ahead and bolted on the new functionality rather than waste the time that they didn't have to analyze whether it would be more efficient.
This reminds me of a time when I had a project manager tell us to do a job as fast as possible and to customize our current methodology for the situation. But of course, when there were the inevitable quality issues with the release, he declared that the root cause was because the company's methodology was not followed by the development staff, leaving us hanging in the wind.
A famous saying on a co-worker's sig was "Quality and Time-to-Market are everything." Too bad you can't have both.
So, like, why are you in software development anyway?
DT
Is this thing on? Hello?
Choose any two.
Ima 'spear-ienced Softwear Projekt Manger. Plus, I've got produkt mangment experience to. And I can market stuff. ANd I have a deep voice, so I sound good in tv pictures.
Seriously. Hire me.
Hire me.
Seriously.
"This is a Website!"
CAn'T CompreHend SARcaSm?
Our industry does what naive works do.
If you can think: Open Source is really bad for the software industry. First of all: Do you get goods in the supermarket for free? Is your medicine free? A lawyer? A doctor free?
NO! But they are benefitted by the Open Source industry,
How many software companies were seriously affected by this movement?
I was explaining this do a doctor once, and he laughted....
If we want to revolute, let's do it for the world, not only for us. This hurts our industry, taking money from it (people don't buy) and send the money to other industries (people use the money to buy a best car).
Do you still think it's better to have software for free? EXPENSIVE SOFTWARE can employ lots of developers. Can generate good salaries!
Software developers, engineers and students: WAKE UP! THIS IS THE WORLD, NOT THE FUCKING INTERNET BUBBLE!
Let make software more slow, better tought, with more people and buying more technology!
Why use PHP or Pearl if we can use paid software like Websphere? This generated JOBS for Websphere developers, for consultants, for everyone.
If you have further questions about "The Real Software Thing", tell me.
Lets make better for ALL US DEVELOPERS!
You can have it cheap, you can have it good, you can have it fast.
.02
;-)
Now choose two.
cLive
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
Congratulations, sir, you just won a new car!
Ive been through the same trauma. Heres what ive learnt :
... all the time.
The responsibility was never on your head. Your manager is kicking you now because his ass is being kicked. He had patted you then because he had recieved good words. it happens
The solution is simple, just be dumb, let your manager do all the decision making, propose to him all the possible alternatives and let him decide, make him realize that he is making the decisions and you are just following them. Next time he gets kicked, he will absorb the shock himself and will not transfer it to you, what you might end up getting is more responsibility and authority to make the decissions on future projects. Decisions then should be made through short but sharp meetings with all the departments involved. (fin, sales, QA,....)
It is always better to do what is best for the company. Doing what is best for the company in the long term mean making the most money for the company. Having a good product helps realize more profits, which makes the project a bigger success. I think that if a strong argument is made for the best long term solution is turned down then there is a real problem with the company.
Regards, Jake Johnson http://www.plutoid.com
(rambling... I'm thinking of writing an article on this soon)
I'm a consultant - regardless of cash flow or size, most organizations I've come across seem to fall into one of two groups:
"reactive" - organization can only think ahead 3-6 months, and are too busy trying to manage day-to-day to do any real planning. These are usually characterized by a management team that is happy with the status quo & is just trying to keep their heads above water day-to-day. This is MOST organizations! They often see technology as a cost center--a liability--a necessary evil they have to keep propping up once in a while.
"proactive" - organization has a much longer-term view & can adjust to new inputs in a smooth, methodical way. This is characterized by a management team that actually has a longer view of things--they see the "big picture" possibly several years down the road. These organizations are great to work for because they value your input & generally don't try to constantly override your suggestions. They see technology as it is--a tool to enable business to be faster/smoother/easier/more efficient/more competitive, and will pay accordingly to set things up correctly because they understand the potential return on investment.
Unfortunately, only around 20-30% of the organizations I've encountered are truly "proactive" - it takes a bit more work and money up front to think "proactively" all the time, but in the end you end up with a solid, smooth-running organization. This methodology always comes from the top down.
My clients are generally the proactive type because I've worked my contracts to be proactive--"reactive" companies don't see the value in paying to have someone maintain their networks, unless something _really_ breaks--and when that happens, they generally throw tons of money at stuff to fix it (always more than it would have cost to keep it properly maintained in the first place).
So I guess this also extends to software development. Doing it right the first time means never having to do it again; saving money & headaches down the road. This doesn't mean to say the quick & dirty method isn't always the wrong way--but it's _usually_ the wrong way if you don't want to have to clean up the mess later on--added to your existing future workload, of course. Short-sighted management is _wrong_ when they insist on doing something half-ass to get it out the door if you know you'll have to redo it later.
Of course, your local politics may vary. You might consider writing a short brief or proposal for your boss that explains exactly what you'll be doing--and how deviating from that plan will cause extra headaches/time/$$MONEY$$ down the road. I find that seeing things written up like this (especially if you can attach costs to it - you can generally get management's attention with actual figures) usually helps make your point. If your boss is constantly telling you to do things the wrong way and generally making your life a living hell, you probably need to get out of that situation.
as a sidenote, regardless of the economy, life is too short to hate your job. You'll figure out a way to make ends meet.
I've been programming videogames for about 7 years, and I continuously improve our code to keep it flexible and reusable, both of which are critical to efficient game development in the medium and long terms (months to years) but not always the short term (days to weeks).
Improvement consists of simplifying and clarifying: function and variable names; tight, non-redundant interfaces and objects; keeping cruft out; constantly evaluating the implementation verses the current need. Keeping functions and objects understandable enough that detailed comments are never necessary.
I take more time with lower-level code because it's used more often, by other code and people. I write mostly low-level code, and probably spend 25% of my time cleaning up already working code.
I've found it best to not fix other people's code, but to let them know what could be improved, and to signal others if it doesn't get improved as needed.
BTW being "correct and proper" often leads to overdesigned, rigid code that is hard to tear down or retrofit as requirements change. Best to do what needs doing today without shutting the door on what needs doing tomorrow. When you do shut doors to keep things manageable, be aware of and tell others what you're shutting out.
The answer to your question can easily be reduced to, "Do you have to support it?"
Seriously though, unless you hate the people that will be stuck with the mess, tell them it will take quite some time to get a solid version out. If they shoot themselves in the foot and tell you they need something by X, then when X comes and it's ratty and buggy and they point their fingers at you, pull out the logs/archives and point right back at them. When they want you to work extra to fix a bug, be sure to point out that they caused the problem, and now they will have to hire someone else to come in and help fix it. You shouldn't be penalized for their short-sited lack of management and planning skills. I would quit if anyone set a deadline earlier than I said was possible without hiring new help. My favorite is when you tell them you could have it by X done right, and they keep bothering you with other problems and wonder why you didn't have it done on time.
If you don't want to work 60h/week patching patches, I suggest you do it right to begin with. I work in a small little IT company, and people look to us to fix their software. A lot of the time we have to tell them their software was developed by a highschool drop-out monkey, and it would take less time to rewrite the whole thing than it would take to make their software work. Usually it's something running on Access written in VBA, that would take all of 40h to replace with a decent MVC serverside scalable extendable application using free or cheap software, assuming you know all the technologies involved.
Karma Clown
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.
There is almost never money available for jobs to be done properly but there is always money to fix problems. I think this is because when something is done right it doesn't occur to anyone that anything substantial was done. When there's some terrible problem everyone suddenly understands where the money needs to go.
We were about to ship our product (after *finally* fixing all P1 bugs, after 4 months of hard effort) to our main, cash cow customer when our Director of Technology decides subjectively from the code that we're not using STL enough. He decides that "1 week ought to be enough" to refactor the code base to use more STL to his satisfaction.
So, we delay the release (despite the release candidate looking solid enough) to make the changes. Our bus dev guy was FURIOUS, but ultimately couldn't do anything but fret. Finally, we get the project to build, only to discover numerous problems - everything from strange slowdowns to intermittent crashes. At least 5 new p1 bugs opened.
Needless to say, the extra 2 weeks that the "refactor" introduced was enough to send our customer running to our main competitor (they were doing diligence on both of us anyways) and eventually the company folded.
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 !
Well, assume you haven't got a lot of money to produce software... So you pay american developers to get the job done quick and dirty The solution is to hire a bunch of indian developers (Bangalore...). They will cost you far less money and you will get the job done the right way instead of "quick and dirty". If india is too expensive: try Romania, Russia and so on !
le souvenir d'une certaine image n'est que le regret d'un certain instant (M.Proust)
Most people wrote, "Write a temporary fix, and then write a good solution after". I say bullshit. There is nothing as permanent as temporary code. Write crap now, and people who have to work on it in ten years will curse your name.
Here's the low-down:
If a feature/product is over-promised by marketing, and no one notices, then your company is too big to be efficient. You can do what ever you want. Marketing over-promised, and no one was savy enough to realize it. How will they ever figure out that you've done a shitty job?
If your company is small, smart, and fast moving, then they'll notice. Check with marketing and management.
A company must act as One; a company where marketing, engineering and management are not in sync will most likely fail.
I have the same problem. It is very rare that I can sit down and do things the absolutely perfect way the first time.
So what I learned from a very successful business owner (has done software for IBM, TRW, Motorola, etc...) and one of my best clients, is that you do the quick and dirty every time to start it off. Then 3 to 6 months after you get version 1 done, start from scratch.
Mainly because as you are doing the Q&D, you want the speed and flexibility of crappy code to get features tested and useability refined. Then when you know what you want, after months of Q&D, then you go for creating what you now know is the best features/usability but with good solid code.
I've heard clients complain about most excellent programmers that engineer the crap out of their code, do everything right, and their code is solid and immaculate.
hehe, yes and these programmers are always late with their code, stuck on their own ideas and are unable to change their perfect code to add new features.
The happy medium I have found is that I maintain a good solid methodogly so that my code is never super crappy, as this is hell to go back over. It takes extra time, but not as much time as documenting and setting up pefect objects on every corner of the project.
I am sure most programmers have some sort of degreee of quality standard they won't drop below no matter how short the deadline.
Right now I am working on an Content Management System that is based on some purchased code. But the current code is pure trash and filth. But I chose to change the big things first. And keep a long term perspective on features vs nice code base. When I explain this to the clients, they tend to appreciate the method of quick code and then clean/redo after the design phase is completed, it just makes sense to the money guys....
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.
We recently swapped out some expensive software (£30k/month) for some cheaper software (£60k + £15k/year) - and found three of four days before the old access was removed that the new solution actually had some pretty big holes in it wrt the web client side. We have contractual agreements with some of our customers that enables them to use the web access - so we needed a solution. I did the quickest, dirtiest, ugliest solution you can imagine. Seriously, it would make your eyes bleed. But it got us live and we fulfilled our commitment to our customers. However, I then had a tough job convincing management that it needed to be done properly. Once I had hammered the concept of what I had to have done across - they were quite receptive. 9 months later I have a Proper(TM) solution, and in all honestly we will probably be ditching the original software. Such is life. Anyway, the point of my ramble is that it is possible to combine a QnD solution with a long term proper one - as long as the powers that be fully understand what is going on. Which is easier said than done....but that is whole other story.
'Internet! Is that thing still around?' - Homer Simpson
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.
(all the people that modded your comment informative are morons, however it was very insightful)
There is pressure to close a quarter and hiring is never done at the end of the year so it doesn't hit the 10k (annual report), however instead of reporting less often so there are fewer measurement points, wait a 100 years (hopefully) and see if we can have weekly reports that are constantly updated at a central server. this would eliminate any of that, even the 4th quarter hiring freezes (unless the holidays fucks up stuff).
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
Many people think reality can be modeled. I like to invoke Taoist theology and point out that as soon as you try to make a model of reality (which is exactly what programs assume) you will lose the infinite facets of the object you are modeling.
Its the whole, everything looks like a spring to a physicist problem. Only when it gets right down to it nothing is that simple. So what do we do about it?
We create a model, make it as flexible as possible, and don't waste time coding the perfect code when the model is bound to change. Thats the lesson the market has figured out that we haven't. We're drawn to the model because we like to put eveything in a box and say "thats solved" when it never really is!
Lou
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 don't see any mention to deadlines and profit.
This guy is great and all, but sometimes you need practical experience on a field to have an insightful opinion about it.
IANAL but write like a drunk one.
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.
Life is too short, family and friends come first, I come second, work is a distant third or fourth.
IANAL but write like a drunk one.
A ficticious god will not help you out.
Get things on paper and do your best while looking for a new job.
IANAL but write like a drunk one.
When I follow the link to your "SID that never gets archived," whatever that means, I get this message: "Nothing for you to see here. Please move along." What is going on? Who are those krouts, ekrouts, surakrouts and other /.*outs/?
This is not the first time I get annoyed this way.
See this threads:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
to have some idea how I have been treated here on Slashdot.
Could anyone please explain me what is going on?
I hope someone will explain it and finally end this farse.
And please don't use such subjects because they not only look stupid, but they also make the page wider than my browser window.
Thank you.
Karma: Positive (probably because of superiour intellect)
Quick and Dirty ... ...
Should be renamed "proof of concept"
Disipline dictates that you throw your proof of concept away and follow a process for things destined for the field.
- Think before you code.
- Avoid repetition - Cut & paste is you enemy. If you're re-using the same functionality over and over again, package it in a function or object or whatever. For some high-level functionality (for example a database access layer) consider code generation.
What are the gains?- Since you thought before you coded, coding will be less of a 2 steps forward 1 step back process (as in "oops, it won't work this way"). This means faster coding and a clearer, cleaner and simpler results
- Avoiding repetition of code will get you a smaller and cleaner code. It will also be clearer, more so depending on naming convention for functions. Additionaly, the "I copied 50 lines of code and changed the variable name everywhere but forgot one place" type of bugs won't be there anymore.
- A smaller, clearer and cleaner code base will have less bugs (it's much more easy to loose your track and make mistakes in monster 1000 lines functions than in 100 lines ones). Less bugs means less debugging time. It will also be faster to fix and change in the future - 5 months later when you don't remember very well how the thing works you will much more easily figure it out again. It's less code to maintain. It won't have as many bugs that need to be fixed
The same principles can be applied at higher levels of the software development process (design, architecture, the process in itself)The higher you go, the more the impact tends to be longer term and higher level (for example: a clean modular architecture will repay the extra effort when you re-use modules across applications).
Things like documentation will bring scalability to your software development process (for example: people can become productive faster in an area of the code they didn't knew.)
In my experience the lower level application of this principles pays itself almost immediatly - you end up delivering faster ('cause you code faster and you debug less).
Using them at higher levels can be more tricky. Since the feedback cycles are longer (it take more time to see to end result of your work), experience will be much more important. Over designing is a risk. Adding un-needed flexibility is a risk. Partitioning things in the wrong way is a risk. It's faster to fix bad code than it is bad design. Sometimes management will stop the design process because from they're point of view no visible outcome is being produced (some managers need to see some form of program working to feel that things are getting anywhere). ...)
Investing in a beter design is more of a risk. On the other hand the rewards are much vaster - coding can quite ofter be done in half or a third of the time; it's the only way to get things like the modules that are reused all over the products in your company and have saved thousands of man days
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.
If the time to market is crucial, do quick and dirty and refactor later.
Use Agile techniques to make refactoring less painful.
As always, the correct choice depends directly on the consequences of each possibility. Which is worse? Getting the contract and dealing with a Quick and Dirty solution... or not getting the contract? Using terms like "rapid prototype" and "more robust solutions" help for explaining why you have to take more time to accomplish the same thing you just accomplished a second time.
Sometimes a "Quick and Dirty" (tm) solution is the best solution since the customer may be planning on "upgrading" (tm) in the future anyway. I have a feeling that your particular issues, however, relate to longer "product lifecycle", and "more cost effective maintenance" issues. Something like : "spend more now so you save money later" just might work with your particular PHB.
Just remember... Software Engineering is... HELL.
[signature]
when they mention process to you, and the marketroids will deserve it.
Keep a notebook to document their abuses.
What?
The YOU ARE SO FIRED! guy's not around when you need him.
Right, this is the last straw.
YOU ARE SO FIRED! IS SO FIRED!
The answer is simple and totally unsatisfying: It's better to do it The Right Way, but you will probably lose your job unless you do it Q&D.
Pass the Quick and dirty solution off as a proof of concept. That should get the customers interest while at the same time leaving you with a job.
I was in the same situation as you were, and I didn't like it. I left, and now work for a company that does things the right way the first time. We can get away with this because our projects are internal and include a lot of Research so tons of documentation, reviews, unit tests, and standards. I think it's a personal preference where someone would rater be, but I've managed to find a happy place for me :)
You actually cry over that stuff? IT'S JUST CODE.
Actually, I don't even think there's such a thing as "Correct and Proper"...just "Quick n' Dirty" and "Slow 'n Dirty"
"UNIX" is never having to say you're sorry.
(JFDI = Just F*cking Do It)
Sometimes you need to drop all the fancy processes-control procedures and fall back on the JFDI methodology.
But make sure you CYA as well.
I find it rare that my upper level management read old emails or looks at documentation to prove what quick and dirty strategy they have signed off on. Putting things like that back in the face of upper level managent within your own company (not outside consulting)can make you look very bad. Its very frustrating so I agree with this problem. Maybe my company doesnt have good responsible management?
Good, Fast, Cheap.
Pick any two.
That, I believe, sums it up.
You're a student employee? I can assume that you don't yet have experience at other development shops then, outside of school.
Honestly, the place you work sounds like an absolute nightmare for developers. But for that reason it might be a good experience to have, because you'll really appreciate more structured development shops in future jobs.
No code commenting? What about documentation? Detailed design docs? Do you even use any change control or source code control?
If that's the way it is, then I bet you guys work a lot of late nights and weekends. Most of what you're doing is either changing other peoples' code on the fly, trying to figure out who changed your code when it doesn't do what it used to, and not knowing what component A is even for, or why it was created-- because there's no documentation on it.
It's great that they have set standards for method naming and variable naming, but are there standards for higher levels of design? For example, using well-known design patterns, object pools, that kind of thing?
And most importantly, what about QA testing? Developers should only be doing unit testing and load testing... if you guys are doing QA testing (just making an assumption here), something is seriously wrong.
The fact that the company was founded by CS PhD's is irrelevant. Being an expert in CS has nothing to do with knowing how to run a company, manage people, or creating a well-structured development shop (which mainly has to do with managing policies and people, rather than code).
Gods, can you tell I'm over, uh, 35? Very few of us get to do it "the right way". Just try to do the most important parts "the right way". Remember to test. Remember to document. Pray a lot, even if you don't believe. It certainly can't hurt.
stirring the pot since nineteen mumblty mumble...
Do the Quick and Dirty. All the products Ive worked on Ive done Quick and Dirty. They arenot crap, but the code is messy and not properly commented. The only product I ever *DID* do properly took 10 years and by then nobody was interested. Q&D always wins. You can clean it up after (your boss) is rich.
You need to get someone in marketing to sign something as part of the normal review process in your development cycle that has something like "Beta" or "Experimental" written all over it. If they refuse, you refuse to ship. If management has a problem with this, you can show them the working quick and dirty solution that marketing refuses to slap a "1.0" label on. Marketing is a proxy for your customer. Just because they're inside your company doesn't mean you should trust them any more.
WARNING: there is a trojan on your
I think that you can turn out a good product quick without having to go to dirty. Your processes should utilize as many tools as possible to make sure that the process doesn't impact the development but still gets good results. As an example using doxygen and mandating a certain amount of doxygen compliant comments be inserted in the code makes it very easy to mainain a system in the future by providing some explination of what is going on. Using a standard codeing format is also good for makeing a product that is easy to maintain. But the standard should be flexable and there should be tools out there that allow you to convert your less cooperative programmers ugly bracketing into a nice uniform code base. The other thing other than tools to help make a product that is quick and good is a good staff. A programmer in C or C++ should be at his fastest be able to pump out some real crap. But a good programmer is one that without taking to much time develop code that is more understandable and therefore a better product in the long run.
Who wouldn't? But what, in the long run, is better for the business? What is going to ensure that the company *is* there in two years?
Yesterday I completed a 3 day class on the CMM (Capability Maturity Model) because my company is trying to get to level 2. Some interesting points - back in 1991, there was one company that was at CMM level 5 - IBM Houston, who was doing the Space Shuttle software. Now there are over 75 companies worldwide.
Now, CMM level doesn't tell you how good your software is, but it tells you how mature an organization is. One very good point that the instructor brought up was that how mature an organization is really shows itself during stressful times. He also said that process improvement isn't the first priority of a business - the number one priority is taking care of business and the customer. I thought that was a very realistic way to look at things.
But think of this: The poster wouldn't be asking this question if the quick-and-dirty solution was used only occasionally. If it becomes an SOP, then you and your company are in trouble.
I tried to relate all the CMM info to Open Source projects. CMM isn't an engineering model, it is a management model. We know that OSS can be very well engineered, but the projects for the most part aren't very well managed. If you have a managed, repeatable process, you can project and plan things very accurately. That gives you credibility with your customers. Over lunch one guy pondered what CMM level Microsoft was at. I said they had no reason to get rated, because they don't have to answer to anyone. They don't need to have schedule credibility with their customers.
The CMM was born out of the SEI and was mainly used by government contractors for years. The government put out an edict that they wouldn't consider anyone for a new contract unless they were at CMM level 2. So companies started getting evaluated. If you have ever been in a CMM level 2 or higher company, you know that things are pretty well-oiled. A lot of people think it is just red tape and management BS, but it can actually help you do your job if you let it.
Hey, I guess I was listening in that class! :-) I know that CMM rating isn't a panacea, but a lot of people are complaining about the software jobs that are going to overseas companies. Most of those software shops are CMM level 2 or higher. If you have two companies that are pretty equal, and one has a CMM level rating and one doesn't, who do you think will get the project? It kind of reminds me of the car industry in the 70's/80's. Japan kicked our asses because we were sitting on them.
My beliefs do not require that you agree with them.
I think the real question here is that you as company need to ask yourselves: "Do we currently have the skills in house to do this?" Too often, I've had bosses throw me into the fire on a project I had no business being on. For example, I ended up getting a crash course in Java, J2EE, Oracle, MQSeries, and Web Logic Commrce on an ecommerce system for a popular donuts and coffee chain. At the time, I was just a DHTML monkey. I was pretty psyched because I was going to be the JSP guy. 3 guys on the project, none with Java skills, let alone J2EE, and 1 month to do it in. The project got done by 2 of the 3 or us and was a 2 months late. Suprisingly, the company that I worked for, Type T, is now out of buisness.
My point is that the quick and dirty approach seems to always apply when you commit to somehting is not your core compentency. In the case of Type T here, they should have NEVER said that they could do the job in a month. They didn't have the people to do it in the 1st pace. So no matter what, we were stuck with the quick and dirty approach. You need to put in about a month of learning Java, the how J2EE works, plus Oracle and Weblogic Commerce. Then once yo know that, youhave 3 weeks left to figure out you're going to get the shit done.
The place I'm at now, we make an e-newsletter system that we resell. While I know it is morally challeneged, we do have some pretty good features and WE KNOW HOW IT WORKS. So when someone needs something extra, it's not difficult to do. Not only that, we can do it properly. However, we do have a similar problem to Type T: account managers sell the platform with features that it does not do. Then they wonder why it will take longer, thus force back into the QnD.
You could always do like one of my coworkers does... take the glory, and then pin the blame on me when people ask questions...
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.
I'd have to say that 99% of the work I do is 'meatball programming' where we write up a quick program to take care of the immediate need (usually its a task to report on system functions or generate a summary of data) and then we go back and make it "look pretty" later when we are out of the crisis phase. I believe that this sort of task management solves more problems than a larger task force sent to research and then overresearch a problem. I've seen way too many problems grow into bigger ones mainly since someone was not willing to take the lead to solve the immediate problem now and worry about the landscaping later. Money is never made or saved by talking about it.
-Cnik
I am against quick and dirty, as stated it can get funding and results. My big hesitation is the statment 'assuming you get money later'-which in my experience never happens in my area. I have worked on several projects where features were done earlier in the quick and dirty way, after some period of time a new feature comes in that affects the earlier work. I knew nothing about the work and the person who did it had left. We had provided estimates and got the funding and now we went to do the work to find out that their was no documentation (just a shell of a high-level design). We had to suck it up and do alot of work to document the original feature first, and then do our requirements document. (yes--we should have looked in greater detail before committing to the project, but we thougnt the original developer followed the process and this was several years later). This has happened a few times, and was even more painfull we had to get to CMM Level II certification. We had to got back and document everything, and it was not the people who originally did the work who had to suffer. We are now being forced to go to III by our clients, and thankfully since we have stuck with the processes established getting level II it shouldn't be that bad. End result, I am for the process to be followed even if it seems to be more painful up front.
Regulations like quarterlies and annuals are the only reason I stay in the stock market. Hell, I'd be happy if the companies finances were totally transparent, not these trumped up, glossy marketing material with (as we've recently found out) criminally false numbers.
The pressure put on companies to make every quarter look like they are financial superstars is purely internal. Quality companies are steady and make gradual income and gradual increases. Any investor who looks at a quarterly report and jumps to the "next best thing" is doomed to paying the government way more than his/her fair share. Companies that focus on stability and long term-growth will draw a crowd of investors that are more interested in the earnings of the company than in the price of the stock (since that's what drives it).
Sorry for the almost rant, but regulation in this (public) industry is the only thing that keeps many of these companies barely on this side of morally upright.
Never go to sea with two chronometers; take one or three.
My development life was heavily influenced by my first job doing, as an in-house IS programmer, we had deadlines but no money value to these deadlines, although some were legal reporting requirements (i.e. taxes, census). Much of the work I did was to modify or update old code written by some anonymous previous employee. By dealing with the maintance of code that was from a year old to older than me, I learnt the important of maintainable code and started to take a longer term view of the software development process. Software doesn't stop at version 1.0, it is only really getting started.
Since then I have had to untangle and update or maintain evil old code, from things like "never more than freshmen 1000 students entering", to "nobody will sniff the network", and hundreds of similiar assumptions that were no longer valid. I am leary of "Quick and Dirty" because these hacks can often outlive their expected life and will need maintance, yet these programs are expensive to maintain because to numerous bad assumption, numerous bugs, and lack of documentation and structure.
I feel sorry for the submitter, he (or she) looks to be in a lose-lose situtation. Either he produces bad code, which have bad assumptions and cause grieve in the future, perhaps not to himself, but to whoever is responsible for support, or write the software correctly, and miss the deadline and risk his job. It seems that if Quick and Dirty isn't "successful" you also risk your job, and if "Correct and Proper" isn't successful you risk your job. Solution? Perhaps, find a more reasonable place to work. If you cannot make you current job a more reasonable place, with more honest and realistic expectations, look elsewhere. Working under those sort of lose-lose environment will not do your mental health any good in the long term, and the company or department will likely suffer in the long term anyhow when it repeatedly fails to met basic expectations of their customers, like producing a working product.
What is success to a geek?
Money, Power, a geek craves not these things.
LilMikey.com... I'll stop doing it when you sto
My big lesson in all this is that you can only do what you can do. Put another way, unless you're really passionate about the goals and ideals of your client/customer, don't sweat it if they want to do things in the silliest way possible. Your duty as a programmer/consultant/wonk is to point out where things might go astray and recommend going the other direction. But if The International House of Monoliths really wants to make stupid choices, hop in the boat and go down with the crew. Do not lose sleep over it.
Of course, in academic or more-idealistic environments, you should feel free to die on every hill if you wish.
Life's too short, friends. Think I'm gonna lose sleep because my latest client has chosen to ignore just about every Java best practice under the sun (under the Sun, even)? A resounding "heck no", I tell you! Think my managers will lose sleep when the time comes to fire my ass because the whole app has turned into the programming equivalent of Viet Nam? Lemme have a "heck no" from the crowd! I say, let 'em lay in their hastily-made and uncomfortable beds. Yes, it's demoralizing, but it's better to me than fighting with your customers/clients only to lose in the end.
In acquiescence, there is bliss.
"Don't matter how New Age you get, old age is gonna kick your ass." - Utah Phillips
And never underestimate your coworkers jealousy.
Do the Q&D version TO THE LETTER of whatever precious little requirements documentation you can scrape into a manila folder. Press them to tell you in their own terms from their own perspective exactly what their expectations are. You must surrender your priorities and divine theirs. Enumerate them in writing and make them choose to agree, disagree, or ignore them. Only do good and right work where it is explicitly necessary to fit the requirements in whatever form they are written down.
When they come back whining about what else they want (in the form of "you should have known to do this"), politely thank them for their new requirements (getting a statement of expectations is good), but remind them that new requirements make the sorting order of the old and new priorities ambiguous. Explain that you don't want to waste your time and their money doing things that are less important than other things which are more important to them.
All of this communiction should happen as informally as possible while still retaining a record of what people said. A good rule of thumb is to refuse to conclude (officially acknowledge) any oral discussion of expectations/requirements without email. Try to start the discussion on email, and keep face-to-face discussions SHORT to limit their scope down to something which is trivial to reiterate in email.
You must accept life in between the Q&D and good and right solutions. Be equally aware of the opportunities and consequences of both strategies in each moment. The better your awareness, the easier it will be to communicate those dilemmas to the customer. Tell the customer a choice must be made, and tell them your recommendations and reasons, but refuse to make those choices on your own. Doubtless your customer fails to understand the nuances of their own problems, you must be dillegent to help them understand as opportunities present themselves. Try to couch your presentation as a progress report: "We passed the last sticking point thanks to your direction, and we have arrived at a new fork in the road."
--- Nothing clever here: move along now...
Clearing major changes with your cowworkers is generally a good thing.
This is 110% true. A group of people who don't communicate is not a team. I've seen what kind of software is built when the team decomposes into people to don't talk to eachother. It is crap.
Worse, are people who chase new buzzwords independently. That team is a non-starter, no matter how much money and PHB speak makes it seem otherwise.
Healthcare article at Kuro5hin
It is usually easier to get forgiveness than permission.
M@
Krispy Cream is people
You are not hired as a programmer. You are hired as a solution provider who happens to be a programmer. If they want quick and dirty, that is what you provide. Imagine you were a contractor, what solution would you provide then?
As an interesting method to help yourself. Spend the few moments designing the solution. Then, implement it quickly. That way, portions of code can be rewritten better, without relying on defaults, and have proper error reporting and the like. But remember, the design is most important. If the design is quick and dirty, the code has no chance of long-term survival.
Have you read my journal today?
Passion is another word that has become meaningless due to overuse and abuse by the marketroids and Madison Avenue. When I hear the word passion invoked these days I tune out because I know a sales pitch is coming. "At Staples we're passionate about paper clips!" Please.
However, it takes immediate courage and alot of initial project planning documentation.
1. Come up with a project plan:
a) Document How, When, Cost and What of the best you can do in the expected ridiculous time frame (including realistic estimates of overtime).
b) Document the same for the "right" way of doing things given that you have already done "a)". I.e. what % of "a)" is "re-usable" and how much time would that part take if you did not do "a)" at all.
2. Present the whole thing for approval to Business (the pushers), the Standards Head(s) (the pullers), and your real boss (the guy who will end up taking the real heat).
Note that approval is not of what to do but that they accept what you say (with the implied threat that they can go ahead and create and take responsibility for all of the details of the project plan, if they really want to).
3. Get your boss to "ask" them to choose which combination of a) and b) that they want done. If you are asking this big question in the first place you do not have the executive authority to make the choice yourself.
I've worked on a lot of projects where the requirements (mostly supporting business processes) change frequently. This happens because sometimes the client didn't know what they want, they didn't really understand their own business process or for their own reasons their business process has changed. In each of these situations the software must change.
The key things I keep in mind are KISS (keep it simple, stupid) and not to over-engineer. Having studied CS and engineering in school I would try and identify similar functionality and factor it out, etc. Then due to changing requirements something would change for one part of the functionality that I had factored, but not for the other. I would have to undo all the factoring I'd done. In the end it would have been simpler to have similar code in 2 places, if the patterns are similar they will be easy to read and maintain.
Now there certainly are times to really engineer a section of code, I've always known that, but I've learned when not to go overboard. There's no point in spending half a day to factor code that already works that very well may have to be undone a few weeks later. It's all about writing good-enough software because the code base is a living document, changing constantly in order to fulfill its role as a business function.
There's a lot of other good comments here discussing situations and angles that I haven't and I agree with many of them. I just want to point out that it may be benificial to not consider some things you may have previously as Q&D, but rather as SIMPLE and GOOD-ENOUGH. Of course there are exceptions, but this is a lesson that I've learned that has really helped my productivity and ability to maintain systems.
Why is it that there isn't enough time to do it right, but there's always time to do it over? When I was a consultant I witnessed many cases of do it now quick & dirty; hardly anyone wanted to take the time to do it right. Funny thing is that after all was said and done the projects that were done quick & dirty ended up costing *more* than the projects that were done right from the beginning, and took *more* time to finish. While I realize this is just my anecdotal evidence, I noticed that the leaders of the projects that ended up being completed on time and within budget spent more time up front negotiating clear requirements from the customers, planning and *thinking* about the architecture which produced a cleaner design, while the coders spent some time *thinking* about the code they were going to write before they began coding. Result? Better design, better code, less panic at the end of the project fixing design and code defects and adding in code for missed or misunderstood requirements.
Besides, doing it right doesn't necessarily mean taking a long time to complete a project - how much time does it take to obtain clear requirements from a customer? How much time does it take to think through the goals of the project and technology involved? Not every project that's done right has to have everything completely specified according to the Rational Unified Process & designed with Rational Rose... Also, how many quick and dirty projects that crash and burn would it take to wreck a contractor's reputation? That will surely result in less revenue over the long term.
Meh.
There is no such thing a Quick & Dirty - only dirty. The best solution is to never tell the Marketing weenies about the 'quick' solution in the first place. You are the programmer damnit, do it your way. Otherwise they will *always* tell you to go the quick route then blame you later. This will continue ad infinitum until so much crap code and bugs build up that you can't ever straighten the mess out. you don't tell marketing how to do their pathetic jobs why should they tell you how to do yours? The clean and proper approach is *always* better because in the long run it *is* the fastest route. Never let anyone, especially someone who has never coded how to do your job.
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
If you are doing the 'quick and dirty' to bring in money/profit for the company and its owners, with no monetary reward for yourself, then you're a fool. If there is not a direct profit, in my pocket, the 'correct and proper' is the only option ever presented. If they don't agree to 'correct and proper' then nothing happens. I refuse to endure the pain and misery of a 'quick and dirty' if the only tangible benefit is to make my boss richer. Heck, ESPECIALLY if the only tangible benefit is to make my boss richer, because the expectation is that 'quick and dirty' can and will be done every time, they (he) will pocket the profits, and I will stuck with the headache, pain and misery of managing and maintaining that 'quick and dirty' mistake for eternity.
To me, code that does not check error conditions is the primary attribute of "dirty" code. So "correct and proper" code would be longer if all you did was add error catching. But the "article" defined "correct" as properly documented, well engineered, process followed.
As a consultant, my "process" is to talk to the client, sleep on it, write code, ask for clarification, sleep, write code, demo it while mentioning additional features that occured to me as I wrote it, repeat as needed, then deploy. I take notes constantly and comment code thoroughly. (Self-defense: I was brought back in 1997 to work on an application I had written in 1991.) I doubt this process is followed by anybody else, but I have yet to have an unsuccessful project.
Design documentation happens during development. I cannot help it. I give functions and variables very descriptive names, such as "counter" instead of "i". I type my design notes as comments, then code around them, adding more comments anytime I pause to think. If there is anything tricky about the data store or the workflow, I add a note that describes how it works.
- Instructions are added during the reviews with the users (demonstrations and training) because then I can see what needs more clarification. Most of the instructions appear where they are needed, rather than in dedicated "Help".
- During a review to make certain that every application followed their guidelines, DuPont called me to ask where was the "Help" documentation for an application that had been in production for 16 months. I asked if anybody had complained or had difficulty using it, wanting to understand what needed to be documented. They talked to the happy users (salepeople, lawyers, and other office workers), and called back with "Nevermind."
"Well-engineered" was the point of my earlier post. A little thought at design time can cut the total amount of code. On performance-tuning contracts, I have replaced hundreds of lines of code with less than 10 lines that function the same, except the new code does MORE error checking. The original code was the "quick and dirty" code written by less knowledgable programmers. It was more error prone, had to have taken more time to type, and needed more QA, which it had not received (which is why I was hired.)
Maybe it is because of experience, maybe it is just my nature, but I cannot use any variable without checking its last use or automatically resetting it.
- I also assume all input is bad. I usually work with Lotus Notes, which never guarantees a field is on a record. So my code always checks if each field exists before getting the value. The habit carries across platforms. I wrote a C program for Oracle data that had these checks in there. Yeah, they probably slowed it down a little, but my client was real happy when the DBA did an "upgrade".
---
C requires much experience in the programmer to be able to catch every possible error. I love its ability to work directly with hardware, but it is a major pain to write code that deals with every possible case. I usually add comments with every function stating what cases are not handled by the code, but this depends on programmers reading the documentation. This is why I prefer Java (today): I give up some control, but development takes less time since more possible bugs are caught during compile. (And you can decompile and read the Java code of commercial products when they do not work as expected. Decompiled C is not much fun.)
Java has the throw->try-catch-catch so that the compiler knows when the programmer was unable to deal with a particular case. It means that programmers who are writing code for reuse can tell later programmers when something is not handled. It beats the documentation method, since programmers can write code knowing the compiler will yell.
- Rarely, the "error" does not matter. An example is an InterruptedException in the middle of a loop that is waiting for another process to finish. T
I spend my life entertaining my brain.
Yes, it is insensitive, but it is fact. Why should I give up, say, 15% of my annual income to feed some poor homeless, my bad, "Disadvantaged" people that I do not know or care for. They are not my responsibility.
Consider the original social system. The wild, before civilization. If you couldn't go out and get your own food, and create your own means alone or with your pack then you died. Simple as that. But now, that is not acceptable. If you can't provide for yourself, then I have to provide for you.
In any society, there are going to be homeless people and others who cannot or will not provide for themselves. They will expect everyone else to provide for them. And in the the USA, as long as they can vote someone will reach into my pocket give it to them.
In my limited knowledge, I think that the USA is as close as we are ever going to get to the way it should be. Just keep voting republican lol. Oh, and even though I am a republican the S11 bill still sucks.
I started work at a company 6 months ago. The guy who wrote the original application finally left after months of problems. His code is HORRIBLE! apparently he used to belittle everyone else and tell them they were wrong. If I showed you his code and gave you his web site address, you could all go bash him, but I can't show the code for disclosure reasons. He did some of the most retarded things and it takes me 3-6 hours to make a simple change to the code. So now, everything has to be done quick and dirty, because the existing code is so bad. Since the day I first got here I've been trying to get the powers-that-be to allow me to re-write the code. Finally we were given permissions and myself and 1 other programmer are working on that now. It took quite a bit of arm-twisting to do it. Sometimes, even planning it out does not equal clean & proper.
-- Does anybody know where the 'any' key is on the keyboard?
I do things quick and dirty, so I have plenty of time to post on Slashdot.
--Drunk as in Beer
Then you have 30 days from scratch, which cannot be extended. In economics it's called "Race to the bottom"
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
I've been manager on too many dev teams where there's too much pressure from the executives about skipping what I call the fundamentals of good software development.
The problem is that most executive "committees" go off and arbitrarily decide ideas, goals, and release dates without even consulting the technology people (and no, a CIO usually doesn't count because their too far removed from the real work). So, the end result is "here's what needs to be done, and we need it by ". Thus begins, the move to quick & dirty - because your job is on the line (how many times have I heard that one before?). My Link on IlluminatiLand
You haven't been keeping up on current events, have you? :-)
The first study you mention, and its conclusions, were obviously flawed in several ways, as the discussion here and elsewhere pointed out at the time. The new Reasoning study, currently under discussion elsewhere on Slashdot as well, finds rather differently, though apparently still suffers from several of the same flaws as the original, and thus has to be taken with the same pinch of salt.
I agree with you that communal development projects, such as much of the Open Source world, tend to attract a certain type of developer, whose motivation and skill level may be higher than average for a number of reasons. However, since many of these guys are also professional developers during the day, and still have a good attitude and skillset then, it doesn't follow that Open Source necessarily produces better code than an equivalent closed source offering.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If it all possible don't hack some code together by trying to code as you go, engineer it! Proper documentation for a project before coding starts will make the coding orders of magnitude easier. Put another way, do a lot of thinking and a little coding.
Get the projects requirements, do an initial evaluation of the time to implement each feature, look at the schedule and decide which features you want to include in the next release. Once that's done, you can generate more detailed specifications for the features and do another round of estimation and eliminate more features if your initial estimates were off. Read Kent Beck's Test Driven Development, Tom DeMarco's Structured Analysis and System Specification, the XP series, Edward Yourdon's Death March and Fred Brook's Mythical Man Month for starters.
If there's not enough time to do everything, then don't bite off so much work. Do not attempt to get more features done by sacrificing documentation and critical thinking. You'll quickly have an application that is a total mess; lack of consistent style, just flat out bad approaches being taken, highly coupled and not very cohesive code, improper use of APIs, concurrency issues, etc. Keep in mind that not all bugs are easy to fix, especially if you can't reliably reproduce the problem (think concurrent programming).
Also, I see a lot of people speaking as if the only value code has is sale value. From what I understand, most code is written to be used internally (use value). This makes proper engineering of an application all the more critical.
There are aspects that can be evolved, and some that can't. XP, as championed, seems to work when the fundamental architecture of the system is either inherited or otherwise done outside of the XP process.
A quick analogy from building construction:
A good architectural design ensures the greatest independence between components, while allowing identification of the critical supporting infrastructure. With the building analogy, I can make the floor a "component" so that I now only care about how much total weigtht, the range of power/water/heat consumption that it is allowed to have, amount of traffic it will generate, etc. That way you can design stairs, supports, elevators, power conduits and plumbing. Interior Walls, lighting and carpeting are all details.
There is a similar need in a system to be built with distributed components to correctly identify the fundamental infrastructure issues. If you mis-identify details as being architectural, you'll bog down the project. But if you dismiss fundamentals as details to be dealt with later, you'll be soon thrashing yourself against those fundamental barriers.
My evaluation of XP remains that it fails to address identification of fundamental architectural issues. But in its defense, the chaos method shoots the messenger for even mentioning them. And chaos is the dominant methodology deployed today.
There must be others, as well...
Actually, there'd be an increase in content. You can't go wrong with kittens. Can we have tiger cubs mauling Teletubbies too?
All code you write should be 100% about maintainability.
Quick and dirty is never really the way out. But not being "quick and dirty" shouldn't always mean a 10 week programming experiment in order to make the "correct" solution though. There is a happy midpoint that you should be striving for.
Focus on making the code that you write intentional and well-purposed. You should always write the simplest code that gets the job done. Don't make every task an opportunity to show off the big brains. In the end you'll just end up having to maintain the code that you write. By writing the simplest code possible, you'll make your code easier to read and easier to maintain.
Simple means that the code is well laid out. It should use patterns that you should have learned in your free time. It should use the best architecture that you know. Sometimes you will have to venture into unknown territory and try some new algorithms and some patterns that maybe you haven't used. Do that sparingly though. You never want to introduce instability into your system by having too many "unknown variables".
If you aren't a good programmer yet, you can learn a lot by reading code -- lots of it. This doesn't mean that other code is better. You'll have to figure out whether it's good by using brainpower. Other code will expose you to ideas you haven't considered yet. Trying a second (or fifteenth) language will help to broaden your horizons. Try taking on a side project at home for a while. If you are a web guy, try doing something with a UI. Diversity will help bring in new ideas.
Read voraciously. Tackle the seminal books on Object-Orientation, Refactoring, and software engineering. Branch out in new directions and read about Aspect-Oriented Programming. Most of all, keep your head screwed on and figure out why to use those technologies.
It is very important to be able to rationalize the decisions you make when you program. When you have a rationalization, make sure you write it down. Put it in comments in the code, but perhaps keep a journal too. I find lots of ideas I had forgotten just sitting in my journal.
Eventually, you may find that you will have to upgrade the algorithms that you originally wrote to be smarter and to take advantage of something you didn't have time to consider originally. This is a good change if you have written good code to begin with.
Finally, work in a place where you believe everybody is smarter than you. Always be the "dumbest guy" and work hard to become the smartest. Working with smart people will challenge you to be your best. Avoid the swagger of a programmer early in your career. There is a lot to learn and just maybe someone else might have something to contribute to your desire for world domination.
How does all this correspond to your question? Maybe nothing. It was hard to tell how much experience you really have -- I just assumed you were new or maybe that you hadn't worked with a lot of good people. Being a good programmer helps to sort these things out in some cases.
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
Well, there's the old "Triangle of Quality" - "Fast", "Cheap", "Good". Pick any two.
It's a reality that people don't know what they want until they see it. Thus, closely following strict standards can slowly get you something that they (your customer) will want to have fixed, even if it is exactly what they SAID they wanted in the first place -- Where a Q&D approach will more quickly get that first product -- which still needs to be fixed -- out the door to them. The Extreme Programming technique tries to address these limitations, and they have some successful approaches which are very slowly being adopted. But in my experience in several software engineering areas -- NASA, IRS, Transportation Systems -- Q&D wins.
Here in the Valley, we play this game.
Two men stand at a busy street corner and watch the women go by. One of them is it.
For each woman that passes, he states immediately, before another one passes, if he would like to spend the rest of his life with her on a deserted island. He picks her.
Rules are:
You can't say "I pick the one before this one".
You can't skip women for any reason. 90 year old crones are still women.
If you don't pick the first nine women that pass, the tenth one is automatically picked for you.
Same goes with software. "Do I do release early and buggy/poorly designed, and capture market share, or do I do it right and risk being beaten to the market?
As in the game, there are no easy answers.
Passion is another word that has become meaningless due to overuse and abuse by the marketroids and Madison Avenue. When I hear the word passion invoked these days I tune out because I know a sales pitch is coming. "At Staples we're passionate about paper clips!" Please.
It was appropriate as used here concerning one's own software development. Great software is written with passion.
rd
DotCom:ResearchLab
(or)
StartupWithCash:OldCompanyLoosingMarketShare
(or)
excitingJob:excitingProduct
You have to find out which side of the industry is hiring.
I work in the building industry as an Architect, but have also done some programming. I deal with issue all the time in buildings. There are 2 types of decisions in design, those that are critical and those that aren't. Without a solid structure the building falls down. Without solid detailing the building leaks, rots and is drafty, and hardware breaks. The color paint is highly flexible. Lucky for us we have 6000 years of building industry experience to back us up. If your goal is masterful performance, every facet must be considered and you need to hire expert craftsman. If it is utility, then pull standard tried and true ideas off the shelf and make them work in extremely obvious ways, so that anyone can pick up a tool and build it, no funkyness allowed. Build according to your needs and remember not everyone is a craftsman, or a grunt.
Unlike in programming, people die if I make a critical error. Also, unlike in programming, performance failure is an open ended, and unlimited legal liability. In the case of negligence, I am personally liable and can have my car and house seized to pay damages.
I also am expected to do things quick and dirty! The only way to make this work is with a clear chain of command, clear expertise, clear product goals, clear budget, clear functional requirements and teamwork. It isn't up to the contractor (or the programmer for that matter) to change the design intent. It is his job to get the job done exactly as directed, because any change to the plan could be a disaster in any large or complicated project. If he is making decisions on his own, they should be decisions within a clearly defined scope, and restricted to his expertise. Contractors always try to do things quick and dirty, I expect this, sometimes demand it, but they are always held to a standard. If they don't like my standard, they shouldn't have bid the project. If they deviate, sometimes they get away with it, sometimes I don't notice, but if something major breaks, they have to fix it until I am satisfied or they hear from a lawyer. It is brutal when things go badly, that is why the people in charge need to stay on top of things, and the people doing the work need to stick to the plan.
If you were a better programmer you could do it QUICK & PROPER... Oh what a concept.. Learn to code.
Modesty is one of life's greatest attributes
I don't know what the problem is. At my job everything is a work around/quick fix. We have work arounds for work arounds to work around the work around that's causing a problem with the work around and then we'll quick fix it later. Despite our arguments nobody seems to care, they just wanted their program yesterday so we do what we can.
Given the choice we'd follow a procedure and document, but that's not really optional at the moment.
It absolutely does not take more time to write good code than it does to write "quick and dirty" code. What it takes is professionalism and pride in your work.
What does it take to refactor instead of copy and paste? You have to be confident in your abilities; you have to be determined to be proud of the work you produce; you have to be fearless; you need to test your work; and maybe you need to spend 10 minutes and some brain power that will save some maintenance programmer hours down the road.
If you need inspiration read Martin Folwer "Refactoring".
If you write in Perl just ignore this post, there is no hope for you.
It took a real world war to end the airplane's patent wars. - Fâché Rouge -