|
Colin Mullikin wrote: He's never been there
Yep, but his smartphone has 
|
|
|
|
|
It is not an imperative indication that you have been there before.
But your phone was probably 
|
|
|
|
|
Jochen Arndt wrote: But your phone was probably
It's time to find out who moved his phone?
|
|
|
|
|
Not necessarily true. If the pub has a sister pub somewhere that uses the same id and password for their wifi and you connected there, then you will automatically connect to the new pub's wifi. Happens to me all the time at Starbucks.
-NP
Never underestimate the creativity of the end-user
|
|
|
|
|
If you don't remember it, but your phone does, it's probably a good place to revisit. Obviously you had a good time the last time you were there, even if - or possibly because - you can't remember it.
Will Rogers never met me.
|
|
|
|
|
From time to time we all do this... a quick and (very) dirty solution to let it go fast and make the customer happy...
Where is your line? When you would refuse (real life samples are the best) your boss to do the Q&D?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Q&D might lead in a dead end street scenario und leave your code full of hacks. Q&D makes sense in the end stadium of a project: if no new features or code reuse is planned.
And it also depends what problem it solved.
BTW: I am currently fighting against a "one shot" Q&D by arguing for a new patch level (by some bugfixes)
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I try to fight ALL Q&D solutions, unfortunately I usually lose.
I have very rarely had a Q&D NOT come back and seriously bite me, yet even when I then prove that it would have taken less time to do a proper fix in the long run, the next day I again am forced to do a Q&D, yes this has happened several times, yes several of those Q&D fixes where to fix another Q&D fix, see where it leads to...
Unfortunately I can't give you any real life samples (would reveal to much)
In my opinion, it's never good to do a Q&D solution so you should always fight it, but in the end it's the boss his/her decision...
Tom
|
|
|
|
|
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.☜☆☞
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
