5 ms·

That sort of business sounds like what we want in milsec and government suppliers, no? Reliable even down to the bug behaviors...

deelly 3y ago
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.
ajmurmann 3y ago
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.
- pc86 3y ago
  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.
  - danbruc 3y ago
    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.
    - pc86 3y ago
      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/ https://xkcd.com/1172/
- birdyrooster 3y ago
  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.
- fivre 3y ago
  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.
  - ajmurmann 3y ago
    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.
ben_w 3y ago
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
- DropInIn 3y ago
  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.
schemester 3y ago
No, of course not, if your military doesn’t develop tech faster than the competition then you lose.

deelly 3y ago

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.

ajmurmann 3y ago

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.

pc86 3y ago
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.
- danbruc 3y ago
  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.
  - pc86 3y ago
    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/ https://xkcd.com/1172/
birdyrooster 3y ago
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.
fivre 3y ago
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.
- ajmurmann 3y ago
  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.

ben_w 3y ago

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

DropInIn 3y ago
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.

schemester 3y ago

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