6 ms·

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The desi

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The design is going to leave out some Product features, the code is going to diverge slightly from the design, QA will find some things the code didn't account for, DevOps, Security, and Legal will each chime in with other things that weren't considered. If the organization requires that everyone is happy, then everyone gets to review the work at every stage (in order to express unhappiness and get it fixed before proceeding). The inevitable result is a Waterfall process to gatekeep how work moves to each stage. The inevitable result is a lack of agility. But if the organization can lean into the Truth that Nothing Is Perfect, that your product is not perfect, your design is not perfect, your code is not perfect, your scaling, observability, security, and compliance are not perfect, then suddenly, nobody needs anybody's approval. You ship, and you ship quickly. Then you focus on learning and iterative improvement. Make things better over time, but not necessarily right now. Getting rid of Waterfall is learning to let go and to live with imperfection.

JohnFen 3y ago
> Getting rid of Waterfall is learning to let go and to live with imperfection. To a degree. But I'm pretty sure one of the reasons why software quality is so much lower these days is because many teams take the idea too far.
nicbou 3y ago
The problem is that some things must be perfect, because they expose the company to significant risk. You can iterate on a feature but not on compliance.
- ilrwbwrkhv 3y ago
  You can iterate on compliance too. Just ask Uber.
- smugglerFlynn 3y ago
  You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion this is not the same as waterfall, and leaves room for experiments and iterative learning. The (very) tricky part, in my experience, is to have these requirements captured in implementation-agnostic way. Even strict accounting reqs require huge amount of work for someone to deconstruct them down to actual compliance requirement, instead of something solution-specific like "we need to store X in component Y". Not everyone wants to invest into this just for agility sake.
  - cushychicken 3y ago
    The PCI Compliance audit commission would surely have some thoughts about this philosophy.
    - oblio 3y ago
      You can just section off the bits that need to be PCI compliant. It would be a good architectural decision, actually.
  - CharlieDigital 3y ago
    > eventually met That might work in some fields, but consider life sciences and pharma where some unmet functional/compliance issue could be injurious to the company, a patient, or both. Waterfall-ish workflows are hard to avoid in such cases. We learned to simply do iterations of waterfall and speed up the validation via automation as much as possible.
    - pc86 3y ago
      Even if that's true - I'm not sure it is, particularly in very early R&D phases with no external impacts - all that means is that non-waterfall doesn't work absolutely 100% of the time, which nobody is saying it does. Any time an engineering methodology is discussed, people come out of the woodwork with their specific example of one time where that methodology won't work.
potatohead00 3y ago
... and leave ops/ devops / are team to pick up the pieces (or put the pieces together) because now your too busy to iterate because your shipping another new thing?
- AnimalMuppet 3y ago
  1. If you're agile, you're not too busy to iterate because you're shipping another new thing. You're able to come back and iterate if that's the most valuable thing you can work on. 2. When waterfall delivers the wrong thing because the requirements from two years ago weren't updated to reflect two years of new reality, someone has to pick up the pieces from that, too. It may not be devops - it might be sales instead. But it's still a problem.
- oblio 3y ago
  The standard fix for this is to put the devs on call. Recurring operational issues get fixed mighty quickly when J. Dev has to wake up a few times at 02:00 on Saturday. Heck, design and architectural issues suddenly get a lot of scrutiny at the whiteboard phase and people decide they don't really need Kafka or Kubernetes or Mesos or GenAI anymore.
  - bobbruno 3y ago
    That thinking is one reason why I left engineering and I don’t see myself coming back to it anytime soon. I don’t like being on-call, I’m not qualified to do Ops-like decisions and I haven’t seen this as the practice in most other industries - Boeing doesn’t have staff flying planes for the airlines, for one. Compliance is a set of stories/tickets/requirements like any other, with a priority to be assigned and eventually worked and reworked at some point in the process. There’s nothing wrong with not addressing it as the first thing - it just blocks release. With that, it will eventually get worked on, hopefully at the time where the pieces that need it are understood and the work to reach it is understood.
  - JohnFen 3y ago
    If anyone is getting 2am calls more than extremely rarely, the process is already seriously broken.
sanderjd 3y ago
I think this is totally right. But some things really do need to be as close to perfect as you can get them. The things in that category that I've run into most are security, privacy, and legal compliance. But in other applications, safety issues would also go in this bucket. So those things really do need a proactive gate, or maybe in some cases, at least an extremely fast reactive response capability. But this just means it is more important to identify the smallest set of considerations like this, in order to give them special treatment, rather than requiring higher scrutiny for everything - if everything is special nothing is special - and to invest in ways for work to be done without implicating those special considerations.

JohnFen 3y ago

> Getting rid of Waterfall is learning to let go and to live with imperfection. To a degree. But I'm pretty sure one of the reasons why software quality is so much lower these days is because many teams take the idea too far.

nicbou 3y ago

The problem is that some things must be perfect, because they expose the company to significant risk. You can iterate on a feature but not on compliance.

ilrwbwrkhv 3y ago
You can iterate on compliance too. Just ask Uber.
smugglerFlynn 3y ago
You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion this is not the same as waterfall, and leaves room for experiments and iterative learning. The (very) tricky part, in my experience, is to have these requirements captured in implementation-agnostic way. Even strict accounting reqs require huge amount of work for someone to deconstruct them down to actual compliance requirement, instead of something solution-specific like "we need to store X in component Y". Not everyone wants to invest into this just for agility sake.
- cushychicken 3y ago
  The PCI Compliance audit commission would surely have some thoughts about this philosophy.
  - oblio 3y ago
    You can just section off the bits that need to be PCI compliant. It would be a good architectural decision, actually.
- CharlieDigital 3y ago
  > eventually met That might work in some fields, but consider life sciences and pharma where some unmet functional/compliance issue could be injurious to the company, a patient, or both. Waterfall-ish workflows are hard to avoid in such cases. We learned to simply do iterations of waterfall and speed up the validation via automation as much as possible.
  - pc86 3y ago
    Even if that's true - I'm not sure it is, particularly in very early R&D phases with no external impacts - all that means is that non-waterfall doesn't work absolutely 100% of the time, which nobody is saying it does. Any time an engineering methodology is discussed, people come out of the woodwork with their specific example of one time where that methodology won't work.

potatohead00 3y ago

... and leave ops/ devops / are team to pick up the pieces (or put the pieces together) because now your too busy to iterate because your shipping another new thing?

AnimalMuppet 3y ago
1. If you're agile, you're not too busy to iterate because you're shipping another new thing. You're able to come back and iterate if that's the most valuable thing you can work on. 2. When waterfall delivers the wrong thing because the requirements from two years ago weren't updated to reflect two years of new reality, someone has to pick up the pieces from that, too. It may not be devops - it might be sales instead. But it's still a problem.
oblio 3y ago
The standard fix for this is to put the devs on call. Recurring operational issues get fixed mighty quickly when J. Dev has to wake up a few times at 02:00 on Saturday. Heck, design and architectural issues suddenly get a lot of scrutiny at the whiteboard phase and people decide they don't really need Kafka or Kubernetes or Mesos or GenAI anymore.
- bobbruno 3y ago
  That thinking is one reason why I left engineering and I don’t see myself coming back to it anytime soon. I don’t like being on-call, I’m not qualified to do Ops-like decisions and I haven’t seen this as the practice in most other industries - Boeing doesn’t have staff flying planes for the airlines, for one. Compliance is a set of stories/tickets/requirements like any other, with a priority to be assigned and eventually worked and reworked at some point in the process. There’s nothing wrong with not addressing it as the first thing - it just blocks release. With that, it will eventually get worked on, hopefully at the time where the pieces that need it are understood and the work to reach it is understood.
- JohnFen 3y ago
  If anyone is getting 2am calls more than extremely rarely, the process is already seriously broken.

sanderjd 3y ago

I think this is totally right. But some things really do need to be as close to perfect as you can get them. The things in that category that I've run into most are security, privacy, and legal compliance. But in other applications, safety issues would also go in this bucket. So those things really do need a proactive gate, or maybe in some cases, at least an extremely fast reactive response capability. But this just means it is more important to identify the smallest set of considerations like this, in order to give them special treatment, rather than requiring higher scrutiny for everything - if everything is special nothing is special - and to invest in ways for work to be done without implicating those special considerations.