4 ms·

There is also a different way around this; Skip all the meeting and ship code into production, and iterate into good solutions to complex problems based on feed

There is also a different way around this; Skip all the meeting and ship code into production, and iterate into good solutions to complex problems based on feedback

pjc50 3y ago
> Skip all the meeting and ship code into production This works until you have an outage, disaster, or embarrasment of some kind, at which point everyone is banned from doing that without approval. This leads to a kind of "trauma driven development"; when you suggest a change, you see a flash of fear in the eyes of people around you. If you punish people for improvements often enough, you don't get any improvements.
- hef19898 3y ago
  Imagine a surgeon would work like this: no prior diagnostics, no procedures to follow, just cut people open and take it from there! Honestly, you shouldn't deploy into production without testing. Development and deployment needs to be tracked and scheduled. Because worst case, it has to be reversible. If you start deploying directly, without coordination with others (skip all the meetings, right?), you are begging for desaster.
  - j4yav 3y ago
    There's always a good case for slowing down and adding more rules. You can even build a whole career out of it, and if you do it right you'll be harder to remove than a tick - simply ensure anything that might threaten you requires your approval and review. Convincing everyone that a mistake deploying software is equivalent to a botched surgery, though, that's a good one! I've not run into that one before but I imagine you could get a lot of mileage out of that at the right company.
    - hef19898 3y ago
      I work in aerospace, last time a company botched software hundreds of people died. Worse than botched surgery. Others rely on whatever software is produced, co-workers, customers, users. I think those people deserve a good quality product. And that requires at least some rules and procedures. Unless, of course, it is a single dev thing. In that case you won't have middle management and performance reviews neither.
      - j4yav 3y ago
        I'd be willing to bet that the most recent mistake during a deployment that an aerospace company made didn't result in many people dying. Maybe the last one you read about in the news, but that biases the selection a bit. That said, if you're sending people to the moon, and are actually working on the system that sends them there rather than the website, feel free to have a more rigorous testing procedure. But if you aren't, consider maybe you don't need it.
        hef19898 3y ago
        An guess why the fuck ups killong people are so rare? Not every industry has to follow aerospace, or life science, standards. Every company owes its customers a good product. And with complexity, product, organisation, requirements, that requires coordination, communication and rules. Ignoring that, cowboy style, not going to meetings, deploying to production directly, not understanding requirements and blaming all of that on management is simply unprofessional.
        j4yav 3y ago
        I'm still not convinced yet that more meetings makes better software, but I appreciate that you have shared your position so passionately and I feel like I learned a lot.
      - ryanbrunner 3y ago
        Obviously the degree of caution necessary depends on the nature of the problems you're solving. But your typical consumer app doesn't need the same degree of caution as aerospace, and using a broad brush to say "everyone must be as risk-adverse as the most risk-adverse company" isn't a great approach.
  - ryanbrunner 3y ago
    You're lumping a lot of things together here. It's entirely possible to test changes and have reversible deployments with them being scheduled or really coordinated with anyone, and "tracking" deployments can be trivially automated as a log of git refs deployed without any real bureaucracy or human involvement.
Silhouette 3y ago
ship code into production, and iterate into good solutions to complex problems based on feedback It makes me sad that this is even considered a serious possibility. It implies that as an industry we have so successfully convinced our customers to accept and pay for junk - as if software being junk is somehow normal or inevitable - that making an effort to competently build a good product doesn't generate enough competitive advantage to be a reliable winning strategy.
- hef19898 3y ago
  Partially, I think, this is due to fast and ubiquotous internet. I remember the days when games were sold on physical media, played single player on a nost of the time offline computer. Same for other software, updates and patches were cumbersome and expensive. Hence, software had to be complete when shipped. Fast forward, today everything can be patched and fixed OTA. It seems that possibility made it possible to ship pre-Beta stuff. That all those OTA updates are an additional revenue stream didn't help.
  - Silhouette 3y ago
    I am absolutely certain you're right. The forcing function to achieve a respectable level of quality before you ship isn't there in an always-online world. The other big factor IMHO is the amount of speculative money that has poured into the industry in recent times. That has allowed a lot of businesses to survive for longer than they naturally could despite shipping junk and that in turn has taught users/customers that expecting better software is unrealistic. Even most unicorn tech businesses (FAANG etc.) still produce a lot of junk and little that is any good - relative to the almost unimaginable scale of resources they have available - because usually they reached that unicorn status by having one or at most a few massive successes that they can defend and that then subsidise all the bad decisions and junk products just as effectively as VC funding rounds.
    - hef19898 3y ago
      Couldn't agree more. We can lament all day long so, it won't change, will it? When it comes to stuff like that, I feel old!

There is also a different way around this; Skip all the meeting and ship code into production, and iterate into good solutions to complex problems based on feedback

pjc50 3y ago

> Skip all the meeting and ship code into production This works until you have an outage, disaster, or embarrasment of some kind, at which point everyone is banned from doing that without approval. This leads to a kind of "trauma driven development"; when you suggest a change, you see a flash of fear in the eyes of people around you. If you punish people for improvements often enough, you don't get any improvements.

hef19898 3y ago
Imagine a surgeon would work like this: no prior diagnostics, no procedures to follow, just cut people open and take it from there! Honestly, you shouldn't deploy into production without testing. Development and deployment needs to be tracked and scheduled. Because worst case, it has to be reversible. If you start deploying directly, without coordination with others (skip all the meetings, right?), you are begging for desaster.
- j4yav 3y ago
  There's always a good case for slowing down and adding more rules. You can even build a whole career out of it, and if you do it right you'll be harder to remove than a tick - simply ensure anything that might threaten you requires your approval and review. Convincing everyone that a mistake deploying software is equivalent to a botched surgery, though, that's a good one! I've not run into that one before but I imagine you could get a lot of mileage out of that at the right company.
  - hef19898 3y ago
    I work in aerospace, last time a company botched software hundreds of people died. Worse than botched surgery. Others rely on whatever software is produced, co-workers, customers, users. I think those people deserve a good quality product. And that requires at least some rules and procedures. Unless, of course, it is a single dev thing. In that case you won't have middle management and performance reviews neither.
    - j4yav 3y ago
      I'd be willing to bet that the most recent mistake during a deployment that an aerospace company made didn't result in many people dying. Maybe the last one you read about in the news, but that biases the selection a bit. That said, if you're sending people to the moon, and are actually working on the system that sends them there rather than the website, feel free to have a more rigorous testing procedure. But if you aren't, consider maybe you don't need it.
      - hef19898 3y ago
        An guess why the fuck ups killong people are so rare? Not every industry has to follow aerospace, or life science, standards. Every company owes its customers a good product. And with complexity, product, organisation, requirements, that requires coordination, communication and rules. Ignoring that, cowboy style, not going to meetings, deploying to production directly, not understanding requirements and blaming all of that on management is simply unprofessional.
        j4yav 3y ago
        I'm still not convinced yet that more meetings makes better software, but I appreciate that you have shared your position so passionately and I feel like I learned a lot.
    - ryanbrunner 3y ago
      Obviously the degree of caution necessary depends on the nature of the problems you're solving. But your typical consumer app doesn't need the same degree of caution as aerospace, and using a broad brush to say "everyone must be as risk-adverse as the most risk-adverse company" isn't a great approach.
- ryanbrunner 3y ago
  You're lumping a lot of things together here. It's entirely possible to test changes and have reversible deployments with them being scheduled or really coordinated with anyone, and "tracking" deployments can be trivially automated as a log of git refs deployed without any real bureaucracy or human involvement.

Silhouette 3y ago

ship code into production, and iterate into good solutions to complex problems based on feedback It makes me sad that this is even considered a serious possibility. It implies that as an industry we have so successfully convinced our customers to accept and pay for junk - as if software being junk is somehow normal or inevitable - that making an effort to competently build a good product doesn't generate enough competitive advantage to be a reliable winning strategy.

hef19898 3y ago
Partially, I think, this is due to fast and ubiquotous internet. I remember the days when games were sold on physical media, played single player on a nost of the time offline computer. Same for other software, updates and patches were cumbersome and expensive. Hence, software had to be complete when shipped. Fast forward, today everything can be patched and fixed OTA. It seems that possibility made it possible to ship pre-Beta stuff. That all those OTA updates are an additional revenue stream didn't help.
- Silhouette 3y ago
  I am absolutely certain you're right. The forcing function to achieve a respectable level of quality before you ship isn't there in an always-online world. The other big factor IMHO is the amount of speculative money that has poured into the industry in recent times. That has allowed a lot of businesses to survive for longer than they naturally could despite shipping junk and that in turn has taught users/customers that expecting better software is unrealistic. Even most unicorn tech businesses (FAANG etc.) still produce a lot of junk and little that is any good - relative to the almost unimaginable scale of resources they have available - because usually they reached that unicorn status by having one or at most a few massive successes that they can defend and that then subsidise all the bad decisions and junk products just as effectively as VC funding rounds.
  - hef19898 3y ago
    Couldn't agree more. We can lament all day long so, it won't change, will it? When it comes to stuff like that, I feel old!