- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
"Bugs! They are good for you"
Admin
Its not a bug, its a feature
Admin
Isn't asking for "features" that essentially scam money from both customers and the government ... illegal ?
Admin
Fantastic story. I am wondering, in the end, was the project considered a success? So was it worse than failure? I guess as long as the developers got paid and the customer was happy there is no good reason to complain even though the programmers didn't like recreating bugs. From what I read they actually did a really good job!
Admin
Merely saying "it's not a bug, it's a feature" is not enough. You have to make your users actually believe it. The former cash register vendor did next to brillant job promoting this unholy slogan. There's optimistic touch in the story though - the vendor went out of business.
PS. We now have tearing-her-hair-girl in ads. I miss you fussball and beanbag girls :-/
Admin
"The client is always right!" Right? No? Maybe!
Admin
David M.'s client was simply compensating for the proces the Government uses (by way of taxes). The system is set-up such that; Everytime money changes hands, the Government gets a little piece of it. In theory, if money changes hands often enough, THE GOVERNMENT GETS ALL OF IT!!
Admin
Some POS companies - for example UK based ones which get very large very quickly by acquiring perfectly good companies, taking the IP and then closing them down, with the corresponding knock-on effect on quality which will obviously follow - save(d) money by simply not testing their software. If it compiles, it's good to go!
Admin
If the company wanted software which looked and behaved exactly the same as the old software... what was the point of re-designing the software in the first place?
And what company would pay for that?
Oh, unless they were an 'Enterprise' company, I can see in a design-by-committee sort of thing that could happen...
Admin
Admin
Programming for retail sales is its own kind of hell, and typically one of the worst-paid programmer hells. I did a short stint with a retailer back during the Y2K days.
They had a series of in-house developed inventory programs that amazed and horrified me. The first day scanning the code I noticed a little gem for "balancing" shelf inventory.
If the inventory DB said there should be 10 on the shelf, and the program found 5, the shelf-count was modified to 5.
If inventory DB said there were 10 on the shelf, and none were counted, the shelf-count was adjusted to -10.
When I asked how an actual shelf inventory could ever be less than zero (in effect 10 - 10 = -10), the accounting team told me it was to adjust for a well-known bug in IBM systems which gave a result of 0 for 10 - 10.
I casually asked how well inventory ever balanced, and was told that the item count was never correct, but stores just adjusted the PRICE PER UNIT until the dollar amount balanced.
Cool.
Admin
I wonder if the programmer would be held liable for implementing software that is designed to short change the federal government. I wouldn't take that chance.
Admin
The client provides demand. The supplier failed to supply. Where's the wtf? Warning a client that their software is not calculating tax, etc is fine but forcing a change to a business process it not. I firmly believe that if it isn't broken, one shouldn't try to fix it. Trying to force the latest and greatest (or even the relatively modern) onto a client who doesn't want or need it is a sure way to lose a client.
Admin
These guys should have just put a plasic face panel over the existing registers, and pretended it was something new that they'd made. Easy money & the client gets what they want quickly.
IBM systems thought that 10 - 10 = 0? How did they ever come to that conclusion?
Admin
Oh my! It sounds similar to my job. We want to keep doing what we've been doing because that's how it's always been done. We don't care if it can be done differently (and better for that matter!)
Admin
Why replace the system then?
Admin
Yes, specifically requesting a feature that calculates incorrect sales tax is highly illegal. In the end whatever sales tax Uncle Sam gets is most likely calculated from the total of taxable sales without all the rounding errors. The extra money that leaves would probably disappear into the gross income (or just disappear, if someone doesn't feel like paying income tax either). Depending on the specifics, it might be impossible to uncover without manually adding up copies of all the receipts, and even then, they have the perfect defense in "the software is faulty".
I wonder what kind of developer goes along with that, and then admits to going along with it, albeit anonymously.
Admin
I find it hard to believe that the company was able to convince the customer to pay for new software and hardware yet unable to convince them to reap any of the benefits in doing so. More likely they didn't try hard enough to explain why the customer's initial position was so utterly stupid for both parties.
Admin
I remember once when I worked for a company that did POS for a rental store. It was discovered that there was a slight bug in the end-of-day report whereby if you ran the on-screen display, then selected "print" it would print a report that matched the items shown on the screen, with the time of the printout corrected.
So, what's the problem? Well, if anything was 'sold' (in this case rented out) after the on-screen display was shown, but before the printout, it would not be included in the report. This was not obvious as individual items were not timestamped on the report.
We told the customer that we had spotted this and would be fixing it... they said "please don't as we run an on-screen display in the back office half way through the day, leave it displayed, then print it off at close of business". This meant that the details shown to the tax man showed half the total turnover compared to what they were really taking, but were timestamped with the correct close-of-business time!
Admin
The supplier supplied to spec. Sales tax calculations are specified by the Government, not the customer. The customer is committing fraud. No software company should go along with this kind of thing, if only to shield yourself from penal liability (indemnity clauses don't really cut it when you've been personally charged with a federal felony).
Admin
Wow, that annoying reminder IS annoying!
Admin
Remind me what POS stands for again...
Admin
So, the client company was committing various types of fraud, and the submitter's company specifically agreed to assist them. While supplying register software that can be used for fraud might not be illegal in itself, if they had good reason to think these tax calculations were actually going to be used then that's a paddlin'. The fact that they agreed to specifically insert such functionality point by point makes it worse.
It's not uncommon for organizations to be willing to pay lots of money for new stuff and pay even more to be protected from any actual benefits and improvements that might result from having new stuff. Sometimes change is expensive in itself. But this isn't really a case of inertia, it's simply a case of fraud and I'm slightly amazed that the submitter's company went along with it with so little to gain.
Admin
Brilliant story. I've been there myself - had to implement a Y2K bug in the summer of 1999 for a major UK supermarket! For the first week of Jan 2000 the handheld barcode scanners would have to report that all the bread had past its sell-by date by 100 years.
Admin
Sometimes? You are way too generous.
Admin
Do they really pull the state sales tax directly from the customer receipt? It seems like they would have an easier way to sum up the sales for the day and just pay tax on that.
Admin
Multiplying the "tax rate" is not always the correct method. I believe most states in the U.S. have tax tables that specifically indicate what the tax on X cents is.
At any rate, changing the calculation of sales tax would genuinely make the company using the POS very nervous, as deviation from proper tax calculation methods could expose the company to fines based on a state government's wild estimation of how much tax revenue had not been collected/reported.
Admin
Admin
Hmm, good thing for the company that it was not mentioned. Now all I'd have to do is tell Uncle Sam that they are being cheated, and they would be audited (I mean, all the auditors would have to do is buy one item with a coupon to prove it). Heck, if any auditor makes a purchase there with a coupon and notices... Could be good business for the programming team, as long as they keep good records that it was the client that screwed it up.
Admin
Hmm, I don't read this as a real 'WTF' case. In fact I don't think the customer was being that unreasonable at all.
Developers like to think they know best, but in the real world the developer's code has to fit into an existing ecosystem. Small changes are important.
The client asked for the new system to behave exactly like the old one. Didn't the developer validate his system? I would expect that he would have tried out the inputs (products being purchased) and compared the outputs (the receipt) against the previous POS terminal prior to releasing to the customer.
No, this is a case of the developer not understanding the client's needs, thinking he knows better, failing to adequately validate his product, then blaming the customer ("Sheesh, isn't it obvious that my way is better than yours?")
Admin
Unlike many programmers who are udder morons. My g/f says I really need to work on my teat handlin' skills.
Admin
If I was the submitter, I would definitely at least send a registered letter and fax saying something like "Be advised that the changes in software you request will result in wrong amounts of tax being calculated. We only do this for you so you can test it and check that this is the case. We can not agree to install this in production environment as it would amount to federal(?) offense."
Admin
Yes, surely assisting in fraud just to be consistent with a broken "ecosystem" is not a WTF at all. Hopefully the customer gets sued and fined for tax evasion just so they realize that they are complete morons.
Admin
As others have said, there's no wtf here. The developer made assumptions about the system's needs, and the customer called them on it. Is David an expert on tax law?
Yes, customers often wish new systems to be integrated seamlessly. This can be inconvenient. But it's a requirement.
Admin
POS = Point of Sale
Working in the industry too...have to define what "backwards compatible" means this week. It does NOT mean the new firmware is the same! It's better but WILL report a different firmware version (that does not qualify for "backwards compatibility" with some companies).
Admin
Yesterday my boss deleted part of one of my bug reports saying "we've always done it that way, it's not a bug," though it's clearly not the intuitively correct behavior.
In the US, we (customers) pay the sales tax on what we buy, so yes, it does have to be calculated based on individual customer receipts. ;) Stores don't pay sales tax on what they sell, they just pass on the taxes the customers paid to the government.
Admin
Does anybody here who is crying "tax fraud" actually know that this is tax fraud?
No?
I didn't think so.
Admin
In fact, after thinking about this for a few minutes, I'm pretty sure the developer gets the 'WTF' award here.
Customer says "Design B so that it works with A".
Developer designs "C" which does not work with "A".
Customer says, "Hey, I asked for B, and you give me C. C doesn't work with A."
Developer says, "Well clearly C is the correct answer, A must be wrong."
Huh? If you asked your painter to paint your room white, and he paints it pink then tells you that he did it because he decided that white would have clashed with the curtains you'd probably complain. This is no different. We're not paid to implement what we wish the customer had asked for.
Admin
Isn't this concept of reimplementing mediocre and buggy code the same as the one behind WINE? (OK ... all emulators, even if WINE is not an emulator)
Admin
Just for that (though I haven't commented on whether it's tax fraud or not), I sent off an e-mail to my dad, who is a CPA. I'll let you know what he says ;)
No, we're not paid to implement what we wish the customer had asked for. But in this case, it looks to me like the client never told the developers they wanted the bugs duplicated - and honestly if someone came up to me and said "I'll pay you to duplicate software X", I would just assume they'd want me to fix any bugs I came across.
Even more so where those bugs affect sales tax calculations and such - not only because the government is getting an incorrect amount of sales tax, but because the store's customers are paying an incorrect amount of sales tax. You'd think a retail store would appreciate being able to charge the slightly smaller correct amount of money for sales tax, because that would pass on to their customers who would be happier at the lower costs.
If the client never stated they wanted the bugs of the original software duplicated, it's not a developer WTF, it's a client WTF, and a potentially illegal WTF at that.
Admin
Actually, allowing -ve values for inventory is a good idea. Here's the scenario:
You're the assistant manager responsible for opening the store. It's December 24. Everyone wants a box of candy canes for Christmas. Last night you ran out. When you opened at 8 am, the truck arrived, but the receiver doesn't come in until 10, so there's no one to process the PO. Meanwhile, there are a bunch of angry customers out there who will personally blame you for ruining Christmas if they don't get their candy canes. In fact, they can see the skid through the back room window.
You have two options:
2 is obviously the prudent thing to do. Programming wise, we just let the inventory go into the negative and when the PO is processed, it will go back to the positive.
Alternatively, we could not let it go negative, and tell the customer at the cash that the product they have in their hand doesn't exist, so they couldn't possibly purchase it.
Golden Rule: When there's a discrepancy between reality and the system, It's usually the system that has it wrong.
Not to say that there aren't plenty of WTFs in the original post.
Admin
To be honest, it warms my little heart to see Uncle Same being scammed out of money that should even be his in the first place. Good for them!
Admin
Captcha: Yeah! I'll be "doom"'ed if I worked on a place like that.
Admin
Many items, typically foodstuffs and some necessities like toilet paper, are sales tax exempt. These items vary state to state. Likewise other businesses and certain individuals can make tax exempt purchases of goods from a business. This is often done on an item by item basis within a purchase.
All this could be tracked, calculated, and totalled at day's end but since it needs to be done and displayed on the individual receipts there's no sense doing it a second time.
There are other reasons too.
Admin
Hmmm, I think we finally understand how Microsoft develops its software.
Admin
Umm, in the USA, sales tax is payable to states and municipalities, not the federal government ("Uncle Sam").
This system never would have worked in my state, Massachusetts, because here there's no sales tax on ordinary food or ordinary clothing.
Auditors, in every state, routinely check this kind of thing over and make adjustments. So, to say this was "fraud" is a big exaggeration. Still, if I were the developer, I'd hang onto the original of that written list of change requests, putting it in the permanent contract file for the job, just in case a law-enforcement person came around asking hard questions.
Admin
OOPs
Well, I omitted pointedly hammering out this was the SHELF count, not the discrepency count, which was also in the DB, but the shelf quantity used as the diffence between expected and actual values.
There was also an inventory count for back ordered items and special orders which were not part of the regular inventory. Those were not accounted for as part of store ON-HAND or shelf counts.
Fudging the store's actual on-hand amount to be (x - x) = -x is dopey. And even more dopey to adjust the stores Price per unit to account for the difference in revenue.
I was very happy my job with them was not in accounting. I was very happy to leave the whole cobbled mess before SOX complience became an issue.
And I'm not inclined to go to jail as an accessory to fraud, no matter who's paying me. I can bet no matter what I was "told" to do to fudge the numbers will have no supporting documentation, and the judicial system will not care how many times I say "They TOLD me to fudge the numbers."
Admin
Which is precisely what they do when reporting to Uncle Sam but not when dealing with each individual customer. So the extra few cents per purchase that the customer is led to believe is rounded-up sales tax, never makes it to Uncle Sam.
If the sales tax were calculated from the individual receipts, the company would have no reason to want to keep the "feature", in fact they'd have every reason to want it fixed.
Admin
As a former state auditor the answer is "maybe". Keep in mind that this is a state issue and the answer likely varies by state.
In my state technically all taxes collected must be remitted. In practice the monthly (or quarterly if the payer is small enough) returns are calculated by total taxable sales per authority times the tax rate. There is a difference between collected and remitted but it is usually immaterial.
A good auditor (which unfortunately is not that common - if you were good you generally wouldn't be working for the government) will test daily totals and calculations and catch them resulting in fines. A mediocre auditor will just test that total taxable daily sales add up to the monthly/quarterly reported sales and not test the tax calculation for the day.
But in answer to the above question it is tax fraud. Not in the collection aspect but if they were not remitting it to the State. From the buyer's perspective there is less of an avenue for fraud in my State as State law allows the purchaser to apply for a refund in cases where the tax is overcollected.
Admin
uncle sam isnt being scammed of money, the customer is.
the software calculates tax on a per-receipt basis only to charge the proper amount to the customer, thus:
the customer never sees it coming before it's in the "tax" line