Hacker News Reader

Comment by david422 | Hacker News Reader

So I worked for a company that had loads of process for even the smallest changes. It was frustrating, but what I came to realize was that the company was not interested in fixing bugs or building features - they were primarily interested in not breaking things/keeping the status quo. This was an established business that was concerned with keeping the business running, not chasing the latest and greatest. Perhaps a lot of it was just CYA, but also means it was pretty hard to "move fast and break things".

View on HN

That kind of slow and steady approach actually sounds pretty reasonable for some cases. Sure it won't win the market for a trendy new consumer app, but a lot of software is basically feature complete and should prioritize stability over whatever's currently cool and exciting.

I have an old account with a bank that has hardly changed its website design in well over a decade. It's great! The information is clearly laid out in tables and everything loads super fast. Every other financial web app I'm familiar with has a much more "modern" design and is categorically worse to use. One site literally takes over a dozen clicks to get to basic information and evey single page load is slooooow.

Bank webpages don't need to be more than HTML tables, with perhaps a bit of JS thrown in to ease element collapsing, etc.

I too worked for Google once.

That sort of business sounds like what we want in milsec and government suppliers, no?

Reliable even down to the bug behaviors...

Not only. Also some software for financial sector, for suppliers, for maintenance too. Basically, anything that do not crash a system could be a feature. And sometime even have logical and good reason to exists.

The reliable bug behavior is an underappreciated point and can be hard to understand. I work on software that gets deployed on-prem by customers and had very powerful capabilities for deploying your own code to it etc. There have been a few discussions about some bug fixes and in particular security fixes being appropriate in a patch release when following SemVer. Something might be unintentional or insecure, but customers might be building on the broken behavior and now deploying a patch breaks their apps. The line can become quite blurry.

This sounds like more a deployment/release process problem than anything else. If the customers are essentially deploying untested code straight to production, they're doing something wrong. It might not be their fault, maybe they don't know they should have a staging environment first, or maybe your pricing model makes it prohibitively expensive. It's not as simple as "your customers are doing it wrong," but if you upgrading a package breaks their production environment, someone somewhere is - or more likely, many people are - definitely doing something wrong.

It is not necessarily about breaking the production system, just breaking the system because it depends on some bug or contains workarounds that break if the bug is gone. Even if it breaks before production it is still broken and might - depending on how old or central the bug was and how much code was build on top or around it - require substantial effort to fix.

100% agree it just sounded like in this instance the first time they'd hear about it breaking a customer's workflow[0] would be in that customer's production environment. I've been on both ends of solutions where customers are either technically or financially incapable of having robust test environments for even critical software, especially if they're relying on someone else to write it.

[0] https://xkcd.com/1172/

Yes this happens all the time, I’ve seen it everywhere I’ve every been an engineer. Bug fix roll back due to causing an outage because it broke the defacto API being depended on.

I have had this concern raised, and I'm unclear how, if you adhere to that model of compatibility, that you don't effectively dispense with semver altogether and make every release a major version bump, as every change is breaking if you relied on broken or insecure behavior in earlier versions.

IMO it makes more sense to communicate the expected impact of the changes, so that downstream can read a patch bump as unlikely to cause issues.

Yeah, it gets fuzzy and loses clear meaning. Unfortunately, major releases are expensive in that support contacts are typically guarantee support durations for major or minor releases. Having dozens of versions that all require separate patches quickly can absorb much of your orgs productivity.

I imagine it depends on the specifics. Closest I got[0] to the defence industry was all the anecdotes my dad had about Plessey and GEC Marconi.

I'm sure it's important to have a stable technology to train on in the military; at the same time, I remember one of their open-days they were showing off a civilian in-flight entertainment system that was so clearly overpriced for what it was that I knew even as I saw it that I could've done better for lower unit-cost. This isn't to show off, even despite my having not yet finished secondary school at the time — my solution would've been little more than "glue laptop to chair/wall in front", as tablets weren't something people discussed much around me in the 90s — it's just that the business solution was really unimpressive.

I assume there's secret military equivalents to that public project.

[0] if you exclude the job interview at Lockheed Martin for the year in industry paid work experience part of my degree, which didn't go further than an interview

If they just buy whatever is most cost affordable then the risk factor for trojans goes sky high. Even with major brands this would be a significant issue (see HDD manufacturers bs with drives shipping with malware in the firmware).

Theres a reason there's so many steps to accept hardware.

No, of course not, if your military doesn’t develop tech faster than the competition then you lose.

Reply on news.ycombinator.com