Assumtion is the mother of all fuckups
-
Also known as the story of the natural key that wasn't.
Wrong is evil and must be defeated. - Jeff Ello
Yes, I'va made a nice living cleaning up engineering evaluatuiions that other companies started and couldn't finish. In every case hundreds, when I finally got to the root of the problem, it was always the one thinbg that everyone assumed without checking. Every time! Now, whenever I start looking at a project, the first thing I do, is start asking fir proof that ALL of the assumptions are warranted. Usually, once we get to the critical one, the project manager sighs and says well now we can fix it ourselves. That's fine by me, I already charged my time and I can work on something really challenging!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I had a customer say to me once, "I won't know what I want until I see it." Yes, that is a direct quote. He was definitely the worst customer I have ever had but there are some serious contenders. The top two are both quite large companies and I do everything I possibly can to avoid buying their products.
We have this as SOP, users come to us with an idea, partial spec is proposed and accepted, prototype developed and then the real requirements begin to emerge. Been doing it that way for 30+ years, I have never worked from a complete spec in my entire career.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
I had a customer say to me once, "I won't know what I want until I see it." Yes, that is a direct quote. He was definitely the worst customer I have ever had but there are some serious contenders. The top two are both quite large companies and I do everything I possibly can to avoid buying their products.
Rick York wrote:
had a customer say to me once, "I won't know what I want until I see it."
Handled properly these are way better than clients that give you a whole mess of specs... specs: often in a small co: written by a boss who doesn't really know what the underlings need nor appreciate how it's done now and even less how it could be done better. often in a large co: written by a bunch of idio "consultants" who get led around by a boss and never really ask the users as all they do is listen to the boss who . For mine, the less specs the better, talk to the users, don't ask them "what they do," but rather "what do they need to get done and what's the best way to get it done (with respect to, if any SOP)" End result is a combination of application and business improvement, the staff will be happy, the boss will be happier as he gets happy staff and improved productivity. Put simply: Show me someone that asks for specs and I'll show you a junior programmer.
-
I had a customer say to me once, "I won't know what I want until I see it." Yes, that is a direct quote. He was definitely the worst customer I have ever had but there are some serious contenders. The top two are both quite large companies and I do everything I possibly can to avoid buying their products.
The problem with those large companies is that nobody takes responsibility and just points to someone else exclaiming "He's the responsible guy !", in Dutch we name this sort of thing "Zwarte Pieten" :-\
-
Also known as the story of the natural key that wasn't.
Wrong is evil and must be defeated. - Jeff Ello
assume makes a ass out u and me
-
raddevus wrote:
I'm assuming you are talking about poorly gathered requirements.
Yes, but not just. I've inherited a database and has been given the task of making it work according to new intentions. And while it's actually quite fun most of the time, I would at other times find it even funnier to meet the original designer and teach him the virtues of normalization using a bundle of nettles.
Wrong is evil and must be defeated. - Jeff Ello
-
Mostly. The biggest problem is that he didn't have the domain knowledge to use the correct keys. Then again, he's been using a surrogate key (identity) for a year table. Yes, it has two columns (YearID, Year) :sigh: .
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
Yes, it has two columns (YearID, Year)
That'd be hysterical if it wasn't so tragic.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Also known as the story of the natural key that wasn't.
Wrong is evil and must be defeated. - Jeff Ello
More to the point, why do we insist on using f*** to represent what we all know it actually means? Same as c***; 99% of English speaking readers, I’d wager, know exactly what word this represents. What’s wrong with using cock up if we want to supposedly sanitise the written word? Asking for a friend! 😂
-
raddevus wrote:
I'm assuming you are talking about poorly gathered requirements.
Yes, but not just. I've inherited a database and has been given the task of making it work according to new intentions. And while it's actually quite fun most of the time, I would at other times find it even funnier to meet the original designer and teach him the virtues of normalization using a bundle of nettles.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
teach him the virtues of normalization using a bundle of nettles
That's so environmentally unfriendly of you. A few strokes, the nettles wear out, and you have to harvest more. I prefer a bundle of rusted barbed-wire scraps. They last forever, and the extra weight adds emphasis to the stroke.
Software Zen:
delete this; -
More to the point, why do we insist on using f*** to represent what we all know it actually means? Same as c***; 99% of English speaking readers, I’d wager, know exactly what word this represents. What’s wrong with using cock up if we want to supposedly sanitise the written word? Asking for a friend! 😂
-
Damn! Even the shortened version of a male hen is obscured. I’m living in a world of censorship
How about the long version, cockerel?
Wrong is evil and must be defeated. - Jeff Ello
-
How about the long version, cockerel?
Wrong is evil and must be defeated. - Jeff Ello
-
More to the point, why do we insist on using f*** to represent what we all know it actually means? Same as c***; 99% of English speaking readers, I’d wager, know exactly what word this represents. What’s wrong with using cock up if we want to supposedly sanitise the written word? Asking for a friend! 😂
To answer your question, it's all about keeping the site white-listed in various filters employed by companies.
Wrong is evil and must be defeated. - Jeff Ello
-
I had a customer say to me once, "I won't know what I want until I see it." Yes, that is a direct quote. He was definitely the worst customer I have ever had but there are some serious contenders. The top two are both quite large companies and I do everything I possibly can to avoid buying their products.
...working with one of them right now...
-
...working with one of them right now...
-
Thank you!
-
Hmmm, never had that problem using identities. :laugh:
"Go forth into the source" - Neal Morse
But did you ever use an identity for a year table?
Wrong is evil and must be defeated. - Jeff Ello
-
But did you ever use an identity for a year table?
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
But did you ever use an identity for a year table?
Yes, but only to define fiscal/business years. The situation described where the only other column is an int (assuming :laugh: ) containing the year is ridiculous. :)
"Go forth into the source" - Neal Morse
-
Jörgen Andersson wrote:
But did you ever use an identity for a year table?
Yes, but only to define fiscal/business years. The situation described where the only other column is an int (assuming :laugh: ) containing the year is ridiculous. :)
"Go forth into the source" - Neal Morse
You're gonna love this. It's a lookup table for fiscal years! :laugh:
Wrong is evil and must be defeated. - Jeff Ello
-
You're gonna love this. It's a lookup table for fiscal years! :laugh:
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
It's a lookup table for fiscal years
In a previous response, you mentioned that the year table only has two columns. Am I to assume that a fiscal year is the same as a calendar year in your situation? Mine are not...customers either start their year June 1 or September 1.
"Go forth into the source" - Neal Morse