Hacker News Reader

Comment by littlecranky67 | Hacker News Reader

Again, arbitrary. You could also argue a JavaScript bug on your site preventing a shop checkout is the worst, because you lose Cash by the minutes.

View on HN

While a front end bug that gets in the way of sales is bad for a business, a poorly designed or buggy data layer can cause issues throughout the rest of the application. It can lead to things like lack of isolation between users, loss of data, data inconsistency, and scalability issues.

You have got to be kidding. Corrupting data for a sale already made is far worse than losing a sale because of an outage.

Not when you’re corrupting only a handful of sales, but losing all of them. It still feels arbitrary to say one is more important for developers to be aware of than the other here.

As long as you have both covered to a reasonable degree within your company/team it’s a waste of time arguing who’s got the most important info in their brains.

One is more important because presumably one is harder and thus more expensive to recover from. Typically the deeper the rot in the foundation, the more expensive the repair.

A data corruption might be also impossible to recover from. You could even only notice it after months of it happening, e.g. if your users spend months collecting data which is only analysed at the end of the year.

You are potentially corrupting ALL of your data, not just a handful. Sure, in the two scenarios you chose to provide (speaking of arbitrary), the JS error is clearly worse. If you take the worst case scenario in both cases, one is much more likely to cause an existential threat to your business.

...that's assuming there's some sort of meaningful liability in corrupting the data, either legal or from PR backlash, but sometimes it feels like many companies have discovered that's not really the case.

> Corrupting data for a sale already made is far worse than losing a sale because of an outage.

I mean, this is still arbitrary. There are millions of small businesses worldwide that do fine with terrible records, but making on-going sales.

If you don't make any sales because of constant outages, you could argue that's worse than trying to deal with corrupted data, especially if you have log files or some other method to recover corrupted data anyways.

You're getting to the crux of the issue now. If you don't have log files to recover corrupted data anyways, or that is you never saved it in the first place -- you CANNOT recover it. If you risk irreparably corrupting old data and new data, what is the value of your software system in the first place? Why not use google forms and google spreadsheets, data entry analysts and a call center and be done with the whole thing anyways?

My point is that the very root of what gives software value is something deeply industrial -- it is a machine that can do something over and over correctly, reliably and without regressions. If you take away that reliability to be depended upon by a business, you are no longer building an industrial strength solution -- you're building a toy.

I think you're proving exactly my point.

SQL is intrinsically very close to the metal of your business logic, especially when it comes to general business logic. General business logic is typically most critical and risky around the surface of payments. A JavaScript bug on your site around your shop preventing checkouts is very bad because you are indeed losing cash by the minutes. A poor domain model that doesn't properly associate active promotions to cart order lines could result in an incorrect charge amount and an irate customer.

Reply on news.ycombinator.com