|
No connection to the comic Griff linked just below, so I'll keep quiet!
[edit] Two others posted it while I was typing.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Ha !!! I didn't see that
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
|
It's NEVER a good time for a tax hike!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
But you may not notice it if Maccabi Tel Aviv wins the Euroleague
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Last week one of our customers was trying to update some data through a web API.
Unfortunately, the data was not inserted through the API and as such was missing some data necessary for everything to work.
I spoke to her on the phone and explicitly said "if you send me the user names and codes (that they have) I can fix everything and stuff will work from then on."
She told me she could send more data, but I insisted, I only need the user names and codes.
She just send me an Excel sheet with 43 fields, but the code field is not included...
I can't help but think they do this stuff on purpose...
|
|
|
|
|
Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
You should create a portal | web page | tool for them to fix their own issues. You should not be in the business of fixing "one-offs" for the end user.
That is the only correct solution here.
|
|
|
|
|
Slacker007 wrote: fix their own issues
And then spend the next three months trying to work out WTE they did to "fix" the issue that's now caused even worse problems in a seemingly unrelated part of the system.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
We have not encountered that problem ever. We have a real world working implementation strategy based on the advice I gave and it has been working fine for over 5 years.
|
|
|
|
|
You obviously have a better class of users.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
No. We write the software that only lets the user do what the user needs to do, within our (software services) control.
If the user needs to correct records in a database, then we provide the GUI|toolset for them to do "just" that. When we (the software engineer) do this correctly, then all is fine with the world. We (the software engineer) do not correct the record(s) for them, which I think is what Sander was mentioning, more or less.
In summary, it has nothing to do with the users.
|
|
|
|
|
That's great - if the users know what the "correct" values should be.
And if they can remember what you've previously told them from one week to the next.
Giving them a tool to make very specific corrections might work, so long as it walks them through, holds their hand, and has a metric crapton of sanity checks.
Giving them unconstrained access to modify the database to "fix" their own problems? That never ends well.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Giving them unconstrained access to modify the database to "fix" their own problems? That never ends well.
I did not say this.
Richard Deeming wrote: Giving them a tool to make very specific corrections might work, so long as it walks them through, holds their hand, and has a metric crapton of sanity checks.
And if you, as as software engineer, cannot/will not do this, then I would have to fire you from my team. Just saying... It is actually not as bad as you make it out to be. As I said, our shop has been doing this for our users for over 5 years now with great results.
|
|
|
|
|
Slacker007 wrote: And if you, as as software engineer, cannot/will not do this, ...
I never said I couldn't/wouldn't.
But unless it's a regular occurrence, it's often quicker to fix the data manually than to write, test, and deploy a tool to let the user do it.
(Obligatory XKCD[^])
And surely it would be better to spend your time finding and fixing the root cause of the problem, rather than giving the users a box of band-aids?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In a perfect world, yes.
Unfortunately, it's not that easy.
First, who is going to pay for such a tool (us, our customer, their customer who we are doing this for)?
Second, this is a situation that we do not actually support. I'm not sure who did this only that I get to fix it.
Last, it shouldn't be a problem in the future (alright, I couldn't type that while keeping a straight face ).
Anyway, I'm not the one calling the shots so I just fix it.
|
|
|
|
|
Seems what was provided doesn't fit their requirements.
No, not what they said they want/do, but in what they actually need and use in real life,
OIOW, the failure is in the req. study.
Why do developers do this?
Sin tack
the any key okay
|
|
|
|
|
We just create software for someone else who sells their product.
They chose our product over others
|
|
|
|
|
So if they don't use the code field, why is it important?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
It's important because the field is what OUR business is all about
They use it, just not in every day life (like a passport or citizen service number).
|
|
|
|
|
Sure, but your perspective and their perspective might not be the same.
You have to hammer in the details that you need, but which they might not care about.
... And remember that their perspective is right, because he who has the gold makes the rules.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
He who has the gold pays us to process their data... And to do that we need their data
Apparently, that field IS important to them or they would not be giving us their money to process it.
|
|
|
|
|
I understand this completely! Not long ago, a client sent a spreadsheet with employee information to be imported into a timeclock application. All of the columns we requested, including the unique employee id were present, and the information went in without a hitch! It's too bad that she had decided to be helpful and sort a few columns before sending it! Somehow, some people with the same last names got their id numbers mixed up. It took a week to get it 'sorted' out! Ahh, fun times!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Commit strip OTD: It’s not a bug[^]
If you document it, it's a feature...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Did they fix that bug in later versions?
|
|
|
|