3 ms·

In my startup, for all the future devspeed promised by developers who pretend to know how to plan, after 4 years we sure lack to see their features. I don’t kn

In my startup, for all the future devspeed promised by developers who pretend to know how to plan, after 4 years we sure lack to see their features. I don’t know, it feels like customers buy our product because has features, but who doesn’t like a good K8s stack. The market never seems to end producing those developers who spend their life refactoring and never shipping anything, nor taking responsibility for the fact that their pile of technologies SLOWS DOWN the other developers while never solving the problems they were implemented for. It’s not a manager problem. Developers don’t like taking responsibility for their mistakes.

deleted 2y ago
[deleted]
klodolph 2y ago
> It’s not a manager problem. Developers don’t like taking responsibility for their mistakes. I’m glad you agree on both of these points. Like I said, it’s a problem with building the right incentives, and a problem with people who are trying to avoid blame. A developer with a good, long-term view has a light touch. On one side, you have reckless developers who ship out buggy products that cause problems for operations and customer trust. On the other side, you have fastidious developers who just keep refactoring everything and never ship features. Sometimes, you find a team that can do both. When I’ve seen this, the team has been made of both types of developers. A mix of skill sets, and a high level of trust that they won’t be blamed for failures (outages, missed deadlines). Your developers who move fast and break things will take the time to write a few tests and break things less. Your fastidious developers will relax their standards a little bit and push out code faster, knowing that their contributions are still valued.
ethbr1 2y ago
Related: I don't know why software estimation doesn't spend more time on risk and less time on estimation. How much risk (to delivery) is left out there? What can we do to reduce that risk? It's a known thing, but seems rarely used in software shops. https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model Who cares if 97% of the code is complete, but the remaining 3% is a critical feature, with unclear requirements, that's never been prototyped, and has no test data?
- lemonwaterlime 2y ago
  The challenge is the mindset in most software shops of "We're not building a space ship". Because of the ability to rapidly iterate, there's a sense of invincibility. As we've seen, however, some aspects of the product should in fact be treated like building a space ship. For instance, with something like properly managing data (so you don't get breached), a detailed risk assessment and robust strategy should be more highly prioritized. For displaying a UI to end users, perhaps not so much, but even then there are accessibility concerns that a good product would address.
  - ethbr1 2y ago
    Safety/security risk is important too, but I was suggesting development keep an eye on delivery risk. I.e. the risk that a project won't be delivered with the expected features and by the expected end date Fundamentally, time estimates are useless without a coupled risk/certainty metric. If you ask me how long something is going to take, and I believe it'll take somewhere between 3 months (worst case) and 2 weeks (best case), what number do I reply to you with? And how do you interpret that number? And how does my reporting change as we get closer to delivery? Reducing the size of work being estimated band-aids the problem, by shrinking the absolute magnitude of the bounds, but doesn't fundamentally solve it. Common heuristics like "double how long you think it's going to take" are other ways this appears.
    - lemonwaterlime 2y ago
      I think we’re in agreement. In my mind, you can even get delivery risk from a safety/security standpoint. As in, the product should be developed on time while accounting for the security/safety stuff. And you get there by placing risk front and center for the entire system from the beginning.
llm_trw 2y ago
>The market never seems to end producing those developers who spend their life refactoring and never shipping anything, nor taking responsibility for the fact that their pile of technologies SLOWS DOWN the other developers while never solving the problems they were implemented for. The market absolutely produces those developers, it's just that their salaries start at 7 figures and go up from there.
advael 2y ago
Of course prioritizing shipping more features is going to ship more features. The whole point of prioritizing engineering is to trade off some speed for other things, like your shit not breaking. The incentives in most companies produce catastrophic failures because the mechanisms for punishing individual failure on speed metrics (the easiest metrics and thus the only metrics most organizations know how to or care to measure) are powerful and numerous but the organization-level incentives don't adequately punish the kind of catastrophic failure we are seeing constantly. That cost is externalized from the organization that failed. Their customers and those customers' customers and anyone affected by the whole world being made of brittle nonsense pay the price and have meager recourse if any. If your reason for prioritizing correctness over speed is because you believe that this will eventually produce more speed, I don't know what to tell you. That's possible and a really nice outcome when it happens, but it's not the point of doing it and it's not the typical benefit
- klodolph 2y ago
  Here’s how I’ve seen this play out at some larger, more bureaucratic companies. (This is just an example, it doesn’t have to play out this way.) You start by moving fast and putting out features. Then something breaks in a high-profile way and the hammer comes down. The environment changes and people start avoiding blame. Some of the effects I’ve seen: - You bring more people into meetings (diffuses the blame when something goes wrong, but slows everything down) - You demand more detailed requirements (makes development more predictable, but good designs tend to evolve and do a lot of discovery) - Tedious work doesn’t get automated, and your headcount requirements go up (because tedious work is predictable, and automation is a risky project) Eventually, somebody in senior leadership (hey, I said “larger company”) notices that the entire org has basically slowed to a crawl and is constantly demanding more headcount, and they have to go in and fix things. Or they decide to axe a bunch of projects, or reorg, or something else. I want to emphasize that this is a possible way that the story plays out, not that the story always plays out this way.
- MereInterest 2y ago
  > Of course prioritizing shipping more features is going to ship more features I mean, I'm not entirely sure on that. Prioritizing shipping features may make a codebase be impossible to understand, so that any additional features take longer and longer to implement. Prioritizing design may make a codebase be easier to understand, such that each new feature can be added with breaking existing functionality. There's a quote I like from Jonathan Livingston Seagull: "It's strange. The gulls who scorn perfection for the sake of travel go nowhere, slowly. Those who put aside travel for the sake of perfection go anywhere, instantly."

deleted 2y ago

[deleted]

klodolph 2y ago

> It’s not a manager problem. Developers don’t like taking responsibility for their mistakes. I’m glad you agree on both of these points. Like I said, it’s a problem with building the right incentives, and a problem with people who are trying to avoid blame. A developer with a good, long-term view has a light touch. On one side, you have reckless developers who ship out buggy products that cause problems for operations and customer trust. On the other side, you have fastidious developers who just keep refactoring everything and never ship features. Sometimes, you find a team that can do both. When I’ve seen this, the team has been made of both types of developers. A mix of skill sets, and a high level of trust that they won’t be blamed for failures (outages, missed deadlines). Your developers who move fast and break things will take the time to write a few tests and break things less. Your fastidious developers will relax their standards a little bit and push out code faster, knowing that their contributions are still valued.

ethbr1 2y ago

Related: I don't know why software estimation doesn't spend more time on risk and less time on estimation. How much risk (to delivery) is left out there? What can we do to reduce that risk? It's a known thing, but seems rarely used in software shops. https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model Who cares if 97% of the code is complete, but the remaining 3% is a critical feature, with unclear requirements, that's never been prototyped, and has no test data?

lemonwaterlime 2y ago
The challenge is the mindset in most software shops of "We're not building a space ship". Because of the ability to rapidly iterate, there's a sense of invincibility. As we've seen, however, some aspects of the product should in fact be treated like building a space ship. For instance, with something like properly managing data (so you don't get breached), a detailed risk assessment and robust strategy should be more highly prioritized. For displaying a UI to end users, perhaps not so much, but even then there are accessibility concerns that a good product would address.
- ethbr1 2y ago
  Safety/security risk is important too, but I was suggesting development keep an eye on delivery risk. I.e. the risk that a project won't be delivered with the expected features and by the expected end date Fundamentally, time estimates are useless without a coupled risk/certainty metric. If you ask me how long something is going to take, and I believe it'll take somewhere between 3 months (worst case) and 2 weeks (best case), what number do I reply to you with? And how do you interpret that number? And how does my reporting change as we get closer to delivery? Reducing the size of work being estimated band-aids the problem, by shrinking the absolute magnitude of the bounds, but doesn't fundamentally solve it. Common heuristics like "double how long you think it's going to take" are other ways this appears.
  - lemonwaterlime 2y ago
    I think we’re in agreement. In my mind, you can even get delivery risk from a safety/security standpoint. As in, the product should be developed on time while accounting for the security/safety stuff. And you get there by placing risk front and center for the entire system from the beginning.

llm_trw 2y ago

>The market never seems to end producing those developers who spend their life refactoring and never shipping anything, nor taking responsibility for the fact that their pile of technologies SLOWS DOWN the other developers while never solving the problems they were implemented for. The market absolutely produces those developers, it's just that their salaries start at 7 figures and go up from there.

advael 2y ago

Of course prioritizing shipping more features is going to ship more features. The whole point of prioritizing engineering is to trade off some speed for other things, like your shit not breaking. The incentives in most companies produce catastrophic failures because the mechanisms for punishing individual failure on speed metrics (the easiest metrics and thus the only metrics most organizations know how to or care to measure) are powerful and numerous but the organization-level incentives don't adequately punish the kind of catastrophic failure we are seeing constantly. That cost is externalized from the organization that failed. Their customers and those customers' customers and anyone affected by the whole world being made of brittle nonsense pay the price and have meager recourse if any. If your reason for prioritizing correctness over speed is because you believe that this will eventually produce more speed, I don't know what to tell you. That's possible and a really nice outcome when it happens, but it's not the point of doing it and it's not the typical benefit

klodolph 2y ago
Here’s how I’ve seen this play out at some larger, more bureaucratic companies. (This is just an example, it doesn’t have to play out this way.) You start by moving fast and putting out features. Then something breaks in a high-profile way and the hammer comes down. The environment changes and people start avoiding blame. Some of the effects I’ve seen: - You bring more people into meetings (diffuses the blame when something goes wrong, but slows everything down) - You demand more detailed requirements (makes development more predictable, but good designs tend to evolve and do a lot of discovery) - Tedious work doesn’t get automated, and your headcount requirements go up (because tedious work is predictable, and automation is a risky project) Eventually, somebody in senior leadership (hey, I said “larger company”) notices that the entire org has basically slowed to a crawl and is constantly demanding more headcount, and they have to go in and fix things. Or they decide to axe a bunch of projects, or reorg, or something else. I want to emphasize that this is a possible way that the story plays out, not that the story always plays out this way.
MereInterest 2y ago
> Of course prioritizing shipping more features is going to ship more features I mean, I'm not entirely sure on that. Prioritizing shipping features may make a codebase be impossible to understand, so that any additional features take longer and longer to implement. Prioritizing design may make a codebase be easier to understand, such that each new feature can be added with breaking existing functionality. There's a quote I like from Jonathan Livingston Seagull: "It's strange. The gulls who scorn perfection for the sake of travel go nowhere, slowly. Those who put aside travel for the sake of perfection go anywhere, instantly."