2

A major application we use has a bug that the vendor is calling (a swear word in our business) "working as designed".

As a programmer / system analyst this is a bug - and against all I have been taught about systems / database programming / multi-user applications etc. should act when erroneous data is removed / marked deleted etc.

The error is that numerous critical at times downstream code (in their own software!) look for a single record in the database for that client current appointment for value "X" (Table = ClientID, ClientVisitID, Code, CodeValue, DateStamp).

This single record holds the most "current" value for data that changes semi-regularly.

If my staff sets the value of "X" to 123 in any document, or datagrid, or entry form, it updates the single record to "X" = 123 (depending on the temporal nature of where the data was entered e.g document created yesterday versus time column in the datagrid for today).

This speeds up downstream systems who need the value of "X" - they only have to look in one place, else decide to look in previous visit(s) for the most current value (depending on rules for how long to look back etc)

If NO value of "X" has been recorded this visit, then there is NO row in the single record table. The downstream system then follows other rules (e.g limits on how long to look back) to get the result.

The Scenarios

My staff records "X" = 100 in the last visit (a day ago)
My staff records nothing this visit
Nothing in the single row table  (for this visit)
Downstream systems retrieve "X" as 100 from the last visit

-

My staff records "X" = 100 in the last visit (a day ago)
My staff records "X" = 120 in the current visit (today)
120 in the single row table, datestamp = today
Downstream systems retrieve "X" = 120 from single row table

-

My staff records "X" = 100 in the last visit (a day ago)
My staff records "X" = 999 (in error) in the current visit (today + 1 min)
999 in the single row table, datestamp = today + 1 min
My staff deletes the record (as allowed by the application)
**empty string (not null) in the single row table, datestamp = today + 1 min
Downstream system retrieve nothing, get nothing from the previous visit**

-

My staff records "X" = 100 in the last visit (a day ago)
My staff records "X" = 120 in the current visit (today)
120 in the single row table, datestamp = today
My staff records "X" = 999 (in error) in the current visit (today + 1 min)
999 in the single row table, datestamp = today + 1 min
My staff deletes the record (as allowed by the application)
**empty string (not null) in the single row table, datestamp = today + 1 min
Downstream system retrieve nothing, and act as if 120 never was recorded**

So - What PROFOUND IRREFUTABLE Software Design concerpt do I need to tell my vendor this behaviour disobeys ?

What Quality standard in programming does this contravene?

How do I frame it in a way that make sense?


  • (just to clarify - the user through the GUI has the "X" values stored in the appropriate table - (a simplification) the document table, the flowsheet table etc - then the underlying applications business logic is what is maintaining the entry in the single row column. This design of single row table is due to de-normalisation required for an Enterprise system with 25,000 concurrent users). – dmc2005 Apr 3 '16 at 12:46
  • 4
    Your question relies on a false premise... that a vendor has to follow sound software design principles when creating his product. He doesn't. The marketplace gets to decide whether that is a deal breaker or not. – Robert Harvey Apr 3 '16 at 16:43
  • 1
    In addition to Robert's comment, there is also no requirement for the vendor to fix his bugs. On the other hand, there is no requirement for you to continue using his software. It might be expensive to switch, but if affects your money, it may be worth the price of switching. Just a curious question, is this medical billing/office management software? – Adam Zuckerman Apr 3 '16 at 18:20
3

Strictly, this is in fact your fault. If the mechanism being employed here to undo changes is "The user writes to the database manually", then it's your responsibility to ensure that, well, you write to the database what you want.

Whilst allowing the user to write directly to the database in this fashion is a terrible design, there is no rule that says that it cannot be permitted to occur in any case.

It's really a question of what the agreed-upon spec said. If it did not include an undo feature, the vendor is well within their rights to not offer a proper undo feature. If you need an undo feature, it should be in the spec. If the spec did include an undo feature, you're well within your rights to tell the vendor that it should actually undo.

  • Sorry. This is an existing system (I'm talking Enteprise level, multi-million dollar license fee). We have found the bug, but can't get them to see the sense this is a bug! – dmc2005 Apr 3 '16 at 12:50
  • 4
    It might not be a bug, depending on what the spec actually says. Customers don't get an inherent right to an undo operation; they have that right if it's in the spec. – DeadMG Apr 3 '16 at 12:55
  • But when you buy a turnkey system, their is no spec. There is a degree of expectation about the reality of how most systems work. If it is maintaining a lookup table that is business practice (underlying code) relies on to do other things, then it can't get into an "inconsistent state" where the software acts irrationally. – dmc2005 Apr 3 '16 at 13:06
  • Well, there must be a spec of at least some description, else how would you know that they offered the features that you want? – DeadMG Apr 3 '16 at 13:26
  • 3
    If the vendor said "working as designed", then that's basically the end of it unless you can find some document that contradicts this design. This is really not a question of software development. It's a matter of contracts. What did your company pay for? Was the feature you were expecting put in some document that shows the vendor agreed to it, either in a specification, a contract or even an email from a sales guy? If not, there's no fundamental claim for it to be there. – Steven Burnap Apr 3 '16 at 17:48
2

Strictly speaking a bug is when the programs behaviour differs from the specification.

Although the behaviour is not working as you would expect it to, however justifiable you think your case to be, realy you are arguing about about changing the specifications. Which from a comercial point of view is completely different from identifing a bug.

Other customers using the application may be used to this behaviour and think it a bug if it changes.

The behaviour may have been left that way because a full undo was considered out of scope, too expensive or time consuming to implement.

At the end of the day software development is beset by compromises both in specification and implementation and 'organic growth' of features which end up producing behaviour which is not always ideal.

If you want that behaviour changed you have to justify the cost of making the change. Academic arguments about 'what is right' wont cut it

1

The biggest problem here is that they're essentially using that one row in the table as a global variable. Having global state that the rest of the application uses is generally frowned upon.

What's also confusing is the idea that your staff "writes to this table". Users shouldn't be directly writing data to a table. Writes should go through some kind of business logic layer, and that BLL is responsible for taking other actions. The fact that a user can just delete a row in a database table and the application is expected to recover is... weird.

What this whole thing lacks is an "undo" mechanism. If you want the ability to undo the entry of incorrect data, then you need to remember an "undo stack" of previous values.

However, breaking patterns doesn't necessarily mean your application has a bug. If the application meets all the requirements in the functional specification (some of which are probably implicit) then it doesn't have a bug, no matter how it's programmed. Don't look for a pattern violation - look for a functional specification violation.

  • Sorry - I over simplified when I posted this originally in the wrong StackOverflow site. What I describe is a simplification. The users "X" value is stored in an appropriate table, and business logic maintains the lookup table for speed - but how they are "recovering" from the user then removing that value ("deletion" = InActive = 0) due to error. – dmc2005 Apr 3 '16 at 12:49
0

When you buy a turn-key system, then it must function according to the manual. If you can show that the behavior is contrary to a statement in the manual, you have a can make a case of there being a bug or an inaccuracy in the manual. If the manual is not clear about the functionality in some case, you have some leverage for making a request... But it still may not be a bug.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.