|
In my career, the 'customer' has largely been internal.
Sometimes, we have to make a quick fix due to time constraints... month end closing for accounting for example. However, those 'quick fix' scenarios should ALWAYS be marked as such and followed up to incorporate a viable solution.
At my previous site, we had a fiber optic converter go bad and no spares for that run of fiber. We had to find a workable solution to get the data from the shop floor - failure was not an option. We found an alternate run and were able to get the data through there. Telling the plant manager he can't have any production data from 1/4 of the mill was not going to happen.
|
|
|
|
|
Mock-ups and demos only, and preferably saved either to a local machine or in a clearly-marked fork, so that it can't find its way into the real thing.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I fight against those all the time.
If it absolutely must be fixed and released in a matter of minutes (I'm working RAD, so that does happen), then I might do it quick-and-dirty, release the fix, then immediately start fixing it up correctly for the next version.
But in any other scenario, I'll put in the upfront time and do it right. If I start getting time pressure from above, my response is usually about the same. "I can do this in [short time period], but it'll be ugly and unstable, and it'll just cause more problems down the road. If I'm going to do this properly, I'll have to [do various things] and it'll take at least [longer time period]."
Of course, if you're talking to customers, and not other technical folks, you're probably better off just giving them the longer estimate and doing it right... A Q&D solution that breaks is worse than nothing at all, because it gives a bad impression of your system, and of you. Even worse, the next time something goes wrong, the users might think, "Well, I could ask him to fix this, but he might just make it worse, so I'll just work around it." Then you have secret bugs accumulating alongside counter-intuitive user behavior, and that's a recipe for disaster.
|
|
|
|
|
Ian Shlasko wrote: A Q&D solution that breaks is worse than nothing at all, because it gives a bad impression of your system, and of you. Even worse, the next time something goes wrong, the users might think, "Well, I could ask him to fix this, but he might just make it worse, so I'll just work around it." Then you have secret bugs accumulating alongside counter-intuitive user behavior, and that's a recipe for disaster.
The exact thing I try to explain to my boss - he is a veteran, but lately got some strange behaviors (love of Q&D for instance)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I have to agree - Q&D is a huge mistake. Either it becomes a permanent part of the project - because "it works so why does it need fixing?" - and you have to maintain it for ever, or it sort-of works and the client thinks you are useless... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Every time someone comes to me with one of these, I give out my tried-and-true quote (not sure where I read it first): "There is nothing more permanent than a temporary fix"
I don't make the decision. That's up to business. I tell them if they want me to do quick and dirty, I'll do it, but in the long run they will pay through the nose if they ever want to fix it. Give them the information, then let them hang themselves make the decision.
A couple years later when they come back and want something more from it, I give them a new estimate which is usually far larger than they were expecting and when they ask why I remind them of their previous decision.
|
|
|
|
|
Be more positive.
I've made 'one shot' web pages for users. If the model gets reused another couple of times I'll usually make a generic solution to it. This lets the DBA do the dirty work from then on and my hands have been cleaned (don't blame me if I'm an enabler).
Not always, but surprisingly often. If there's a lesson, it might be artificially constructed to imply: enough bad could can lead to good code.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
...and it gotta be a best seller![^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
I think those are definite sellers 
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: Googling the Error Message[^]
But there is no other available course of action!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Oh My God, now you make me feel a bit guilty!
|
|
|
|
|
Now I know what I missed by being a self-taught programmer instead of University spawn.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
ΓΡΕΕΨΕ (6)
A really easy one today as I won't be around to add hints - Good luck!
|
|
|
|
|
GREECE would be just too obvious. So is CHEESE.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Greece it is I said it was easy. You are up tomorrow.☜☆☞
|
|
|
|
|
|
...but not from us...
(one of the floating sentences during the W10 update process)
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Dilbert OTD[^]
At last we found out... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
they forget to make sure all cover is ugly
|
|
|
|
|
Forgot the marketing campaign to make sure everybody was convinced that it was the cool gadget to own.
|
|
|
|
|
|
Reminds me of Elmer Fudd.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Maybe why it has;
invoke FUDD-THUNK
|
|
|
|
|
The real question is "What was Maunder looking for when he stumbled across THAT?"
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
