|
Sometimes, defensive (employing rules that prevent the user from shooting themselves in the foot) programming/design can come back to bite you. 
Consider this: A simple data collection/reporting application for vending machines. A couple of properties of a machine are initial meter reading and initial meter reading datetime. Once a machine has been setup, users log meter readings and money collected.
The rules are simple:
0: Datetime for a new reading must be greater than the previous reading datetime.
1: Meter reading must be greater than or equal to the previous reading.
If these rules are violated, the screen warns the user and refuses to save.
Did anybody spot the design/logic flaw here? 
For two years and 58 vending machines, this model has worked perfectly, but real life has a way of disrupting the model.
Rule #1 is a problem if the meter gets reset to 0 or the meter/plc gets replaced! Apparently, this just happened on one of their machines, and now the customer is unable to enter a new transaction! 
Sure, there are multiple ways to deal with a 'once in 2 year' glitch:
0: Manual entry (with a note) behind the scenes to force the new entry. This creates a huge overage for that transaction (against actual cash/cc collected) and creates other chaos with the 'order of things' in some reports.
1: Tape a note inside the machine informing the user to add X to the current reading before entering into the system. It's only for a few months until the end of the FY.
2: Create a new vending machine.
3: Alter the previous transactions to negative numbers thereby keeping the flow/order/calculations correct.
1 or 2 is what I'm pushing for, but my bp disagrees and thinks I should modify the app to enable a reset gracefully. I don't disagree, but it's not a priority.
One of the most challenging parts of this job is premonition...anticipating the edge cases before they happen. I do my best, but it's often misunderstood as negativity or introducing unnecessary complexity to a problem. At least it stays challenging! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
modified 21-Apr-22 15:21pm.
|
|
|
|
|
Option 4: Add a setting that is automatically added to the reading. This can be 0 for most machines and a sensible value for the machine you are 'hacking'
Quick and dirty.
|
|
|
|
|
 That's actually a pretty good idea. Thanks! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
kmoorevs wrote: 0: Datetime for a new reading must be greater than the previous reading datetime.
1: Meter reading must be greater than or equal to the previous reading.
Well, for one thing, if local time is being used to track those transactions, rather than UTC, then if you're in a timezone that observes DST, every transaction will be rejected for a period of an hour when the clock gets moved back...
|
|
|
|
|
Use EPOCH timestamp that Unix/Linux uses. Make it 64 bit to make it last beyond 2038.
Don't know what a meter reading is so no help there.
It's been my experience that users will eventually find a way to break code.
Just a question of accidental or on purpose.
|
|
|
|
|
dandy72 wrote: if you're in a timezone that observes DST, every transaction will be rejected for a period of an hour when the clock gets moved back...
OK, you got me there.  Can you imagine an underpaid manager taking meter readings at 2AM on Sunday? Thanks for the heads up, but I'm willing to take that risk.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
In my defense, I had very little context to work with. This could be some automated system that's working on transactions coming in 24/7.
Besides, it's an easy fix. Why risk it?
|
|
|
|
|
Overvalidation requires overtesting which itself causes more churn. That's the brutal irony of the situation.
The other day I spent almost an entire day poring over a routine because the test for it was broken - but it wasn't even the test itself, but bad metrics in a font file i downloaded.
I also can't count the number of times I've had to remove parameter validation as routines get nested inside the internals instead of being part of that API's surface area as things evolve, or to extend them with optional (read: nullable) parameters.
But worse is a situation like you describe. It's not an edge case - and the reason for that is you don't know all the situations in which the machine can be reset, necessarily - or do you? What about an EMP? Ergo, it's a failure condition that's not being handled gracefully. Therefore, it's a design flaw, and one that would have been non-obvious to catch in the design phase.
You got bit, only I don't think you did anything wrong, because erring on the side of overvalidating is better than the alternative, but honestly, I would have done your time validation at another level, like halt if the clock isn't greater than the last time you read it, and I would have skipped the transaction amount accumulation checking altogether barring a scenario you can think of where it's necessary.
Can you pull it out?
Can you adjust the clock code so it checks that the clock's good on start, instead of checking it where you are? That way all you theoretically have to do to restart it on a machine reset it set the clock.
I'm flying blind here, so I may be talking out my backside, but all of this is just stuff that occurred to me.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Sounds like your data model needs to track the PLC and the case as 2 separate entities.
I think the new PLC should start as a new PLC-30 (0 initial start) placed in CASE-10. PLC-04 previously in CASE-10 is retired/scrapped.
Just keep an eye on the collectors as they will find new ways to trick the cash control reports. Like entering negative currency on PLC-04 to balance what goes in their pocket!
|
|
|
|
|
I usually go for minimal validation for exactly the reason you describe.
I ask myself, do I really need this value for the process to work?
If so, it's required.
And also, should a value have a maximum length for it to be saved in the database?
If so, I add a maximum length.
The latter is rarely a problem since I give my field lengths a value that's definitely high enough (usually something like four times the length I'd expect).
And often I make a unique validation, like on a unique code or key.
Other than that, anything goes (unless explicitly specified).
If the data is wrong I can always tell my customer it's their data.
Of course I can write an extra validation, but they should also validate their process so it won't happen again.
|
|
|
|
|
kmoorevs wrote: Meter reading must be greater than or equal to the previous reading.
I hope that the machine itself submits the reading. If it is read by an operative who then posts it, you have greater problems.
I still submit my electricity meter reading 'manually' and have once got the digits wrong which gave an excessively high reading, followed by a much lower correct reading. Now my electric meter has an odometer style display that is in the 900000s and only has six digits; when it reaches 999999 it will roll back to 000000 - I am already worrying if my supplier will be able to cope with that.
The flip side is that 'modern' design principles (XP - Extreme Programming) say you should only cater for the 'known' and not pre-guess the 'unknown'. It is called YAGNI "You Ain't Going to Need It" / "You Aren't Gonna Need It".
|
|
|
|
|
I think that's up there with rolling back the odometer on a car. Create a new "machine account" (with maybe a link to the old one).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I am looking for contracting companies hiring programmers/developers.
Any recommendations?
ed
|
|
|
|
|
Most of my connections are from personal network (been on the same gig since 2003).
Are you looking for work?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Yes. Just quit my current job as the boss is a real a** h***
Can send you a resume, if you like.
Thank you for your reply.
ed
|
|
|
|
|
Quote: Yes. Just quit my current job as the boss is a real a** h***
Quite risky for such a statement as long you have your employer in your profile? 
|
|
|
|
|
flexjobs.com. [^] I know people that have found great gigs from this site. Costs $ subscription per year, but effective.
you may also want to get a premium LinkedIn account. I have one, and it has been super helpful for me.
|
|
|
|
|
Thank you. I will look into it.
|
|
|
|
|
|
|
My idea of marketing myself as a contractor: "I may be a whore, but I ain't cheap."
Software Zen: delete this;
|
|
|
|
|
Yes. Me too. That is an avenue I am pursuing, currently.
|
|
|
|
|
I appreciate being put on "Hot Threads.
However, I don't find the caption "
"Why don't you get a haircut and get a real job?" to be a laughing matter.
|
|
|
|
|
That's a line from a song by George Thorogood and the Destroyers.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Funny Note...
You probably have a decent haircut by 1970s standards...
And you are LOOKING for a job...
So, the comment kinda nailed it. It simply brought up a memory, and it made me look.
I thought NOTHING less of you upon reading the comment, because the comment is the kind of sh!t I say!
Good Luck!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
