 |
|
So we have some software that is written by another company.
A new screen on the web app has a time field that can be filled in by the user.
This field is validated to ensure it contains up to 5 numbers or punctuation characters.
For example 945.2, 27:4, 12/75, and so on.
This data is then exported as entered.
This is causing us one or two problems at times when trying to put this data into another system.
They say that putting in validation for an actual time is a change request and needs paying for.
I say it is piss poor coding that a high school student should be embarrassed to do and they should fix this bug free of charge or stop pretending to be a software company.
What say you?
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
ChrisElston wrote: What say you?
Find a better company or switch to in-house-development. It is even poor that they have no real validation for the date.
|
|
|
|
|
If the spec or requirements stated that it's a time field, then it's a bug - nothing more, nothing less. I would have no hesitation in my company fixing that "Free Of Charge" because it's clear what it should be.
|
|
|
|
|
Five minutes' coding plus an hour's testing?
I'd say it's time to look for other providers.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
ChrisElston wrote: They say that putting in validation for an actual time is a change request and needs paying for.
If the spec indicated the field would be validated, it's a bug (and should be fixed per the provisions of the contract). If the spec indicated the field would not be validated, it's a change request. If the spec didn't indicate whether or not the field would be validated, it's a bad spec. 
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: a bad spec.
Even so, a professional organization would ask for clarification.
|
|
|
|
|
|
What caught my attention was this:
ChrisElston wrote: This is causing us one or two problems at times when trying to put this data into another system.
I don't know the specifics, but on the surface I'd say it isn't their job to make sure the data works with other systems.
For example, if you've been using this system for years and the date field hasn't been an issue - and the introduction of a new system made it an issue - then I don't see why anyone would expect the change to be made for free. It could be they've other clients who demand the field be less strict. Some clients may see these as date values (May 5th, 10/10/10, Tomorrow, Next Week).
The change may require a great deal of work if previously entered date values need to be edited to conform to the new validation rules. Are we talking hundreds, thousands, or millions of records here?
|
|
|
|
|
It isn't their job to make sure data works with another system.
I would say it is their job to make sure that when they crate a form to capture a time for us that it is actually a time that they capture and not a load of meaningless bollocks that the user has bashed in with their elbows.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
For how long have users been putting in meaningless bollocks?
Have you had the system for quite a while?
How many records need repair?
|
|
|
|
|
Two months.
We don't care about the existing data, we just want all future data entered into the time field to actually be a time.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
ChrisElston wrote: For example 945.2, 27:4, 12/75, and so on.
Given that none of those look like a time values to me, I'm not exactly sure what the issue is - my brain can't even figure out what you mean by "945.2". Is this 945 minutes and 20 seconds, or 2 seconds, or 945.2 minutes, or what? And what in gods earth is 12/75?
Also, if you're putting the data into another system and it has issues with your data, I tend to think that that's your problem, not theirs. If they are expecting a valid time value, then why should they put in the validation? Yeah, ok, maybe they should as a good programming practice, but I can also argue the case that they have a right to expect correctly formatted values from you.
Marc
|
|
|
|
|
945.2, 12/75, these are examples of what the system will accept as a valid time.
Clearly they are not valid times.
The field is user entered, it can only ever be a time, it is always auto-populated with the current time but the user can then change it to whatever they want. Or more accurately something other than what they want, but as they hit the wrong keys and then pressed enter the meaningless crap is what we get.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
ChrisElston wrote: Clearly they are not valid times.
I see.
Marc
|
|
|
|
|
Chris, as an accountant, who only codes for personal/private company business, and not for general public release or commercial purposes, I must say that even I would validate an entry for date.
(Actually I would put in a calendar dropdown and be done with it).
So for a supposedly professional outfit to code like that is amateurish, incompetent and lazy.
I think you can safely tell them where to stuff it and how much they could charge!
---------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC Link[ ^]
|
|
|
|
|
To play the dave's advocate there I think it's dependent upon use.
I could see an informal time value being useful.
For example: 'tomorrow', 'later today', 'after lunch' are all valid time values that we all use every day. Maybe there was a request to keep the time field very flexible in this way?
As another poster mentioned, I don't see where the time values make sense without AM/PM designations or unit (days, hours, minutes, seconds, milliseconds, etc.) I cannot make any sense of the time values Chris supplied - but then I don't have the context either.
|
|
|
|
|
Their context is they are typos.
It has lazy validation, ie it can be up to 5 characters in length and the characters must be numbers or punctuation.
They had known they were going to put some validation in but did it very badly indeed.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
ChrisElston wrote: up to 5 characters in length and the characters must be numbers or punctuation
Was any validation specified in the spec or is this what they decided on all by themselves out of the goodness of their hearts?
|
|
|
|
|
How much are they charging for the fix?
Just curious.
|
|
|
|
|
No idea, nothing to do with me.
We'll probably pay for it, cos that is the nature of the beasts involved.
For me it is just a matter of principle. If you create something you claim is a time field then you make damn sure that only valid times can be entered.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
Admittedly, I couldn't find a good justification for numbers and punctuation as a validation rule. If the validation rule was lame that would be one thing; however, the rule as you described is actually bizarre.
|
|
|
|
|
It was a cheap attempt to allow the separator between the hours and minutes I believe.
A time should be of the form 15:20, 15.20 could be allowed, really you should make a decision as to what separator to use and then stick with it, but still.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
I've some more questions but I've got to take a break.
I'll be back at 4$.30/
|
|
|
|
|
Well played.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Shed Petition[ ^]
|
|
|
|
|
MehGerbil wrote: I'll be back at 4$.30/
Nah. That wouldn't pass validation. Longer than 5 characters. 
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
|
|
|
|
|
Oh noes!
The validation on CP is even worse!
|
|
|
|
|
Sounds like a bug to me.
Did the original spec say it was a time field? Did the spec indicate it should be validated?
If so, then they should fix the bug for free.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
ChrisElston wrote: it is piss poor coding that a high school student should be embarrassed to do
I agree.
ChrisElston wrote: they should fix this bug free of charge
Yes, even if the spec doesn't specify, they know better. It's almost as if they're trying to make a point, but that's still unprofessional.
|
|
|
|
|
ChrisElston wrote: They say that putting in validation for an actual time is a change request and
needs paying for.
I say it is piss poor coding that a high school
student should be embarrassed to do and they should fix this bug free of charge
or stop pretending to be a software company.
I would say that this is something that the specifics of the purchase agreement should spell out.
A "software company" should know to refer to that rather than arguing about it.
Additionally the company making the purchase should have specified as part of the purchase agreement that the product would need to pass an acceptance criteria test before being accepted and certainly simple user input validations should have been part of that test.
The final part of that is also a recognition of what the 'user' is. For example data entry help center personnel would have a higher accuracy rate versus standard consumers. The acceptance criteria testing should have taken that into account but if call center personnel are the problem then produce a report that indicates the success rate of individuals.
|
|
|
|
|
I can see this from both sides.
But I can't think of a circumstance where better time validation shouldn't have been performed as a matter of course by any professional.
Unless someone somewhere specced the time to be 5 numbers or punctuation (which surely allows !!!!! as a valid time) then they have not provided a Time entry field.
Having been on the receiving end of something like this myself, I went back to the developers (who had estimated a few thousand dollars for changes that were plainly bugs) and suggested they fix the bugs for free, and quoted for the changes only, or I would perform a thorough test and comparison with the specification and have them change every difference that was not confirmed in writing.
They folded, but I know they just upped the cost of future change requests to compensate themselves.
Incidentally, one of the 'change requests' was to stop the web page continually re-submitting customer's credit card details (and debiting the card) after a warning (rather than an error) code was returned. e.g. if you paid for something and your card was due to expire, but hadn't expired yet, their software would just re-submit the purchase, until they eventually got an error because the card was overdrawn!!
|
|
|
|
|
I agree with your point of view, but if the original development contract didn't explicitly require that datetime entries be validated, you're pissing up a rope. They wrote it this way to ensure that you'd request a change, and thus profit from low-balling the original contract. Never forget that mentality, and do all that you can to encourage others to expect the same level of performance from this company until they have no more customers at all.
Will Rogers never met me.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
