Hacker News Reader

Comment by pcsanwald | Hacker News Reader

I think it's rarely that straightforward. Think about how all the different ways software evolves: one way is, code is written when the company is first getting going, and before you have users or revenue or any kind of product/market fit, it really makes very little sense to be writing bulletproof code. "Quick and dirty" is a rational decision at the early stages of a company.

A small subset of these kinds of systems end up at big companies, because they're acquired, or because the company grows, etc etc. How do you draw a line in the sand where everyone stops the world and re-implements all the "quick and dirty" stuff?

I briefly worked in construction and I've seen plenty of "quick and dirty" there, also, particularly in suburban renovations. Time is money in these projects, and corners are often cut. I'm not saying all engineering works this way, clearly building bridges is a different matter, but I am pointing out that there is a spectrum.

View on HN

> A small subset of these kinds of systems end up at big companies, because they're acquired, or because the company grows, etc etc. How do you draw a line in the sand where everyone stops the world and re-implements all the "quick and dirty" stuff?

Quite frankly, it seems like you nailed the point when someone should be re-implementing the quick and dirty stuff; the moment it gets acquired and integrated. I do understand what you're saying, but I cannot agreed that just because something is difficult to do means that one can hand-wave responsibility. In the case of large companies that have been subject to breaches recently, the only reason they get by after the fact is because they can afford to; if it were to happen to any of the small shops running in "Quick and Dirty" mode and something happened, the shop would more or less take a hit it could not recover from.

I see this in action and hear the same excuse every single day with my clients, and it doesn't matter if they're a multi-national whose infrastructure spans continents or some dude with a pirated hyper v host in his room, the excuse is always the same: "Oh we had to do it that way, and didn't have time to fix it."

Quite frankly, it's non-sense, infinitely moreso in virtual environments. The workflow and technology available for patch-testing, deployment, and rollback has never been faster, safer, or easier than it currently is; companies just aren't doing it, and no one is holding people accountable for negligence. If the aforementioned construction workers who did a quick and dirty job cause major damage to the house as a result, they would be liable for damages due to their negligence. I'm not sure why we in the Tech community somehow think we're above responsibility for our negligence.

I understand that money is on the line - I deal with clients where every minute of down-time has a substantial dollar figure attached, and there's always the attitude of "we'll deal with it later"; and yet, this attitude always ends up causing more trouble in the end, and naturally costing far more.

Edit: Changed "...responsibility for our own negligence" to remove "own"

Reply on news.ycombinator.com