3 ms·

> No matter where I look, up and down the stack, across different OSes and tech stacks, there are bugs. I’m not sure I’d go quite as far as GP, but they did ca

by stouset 6mo ago

> No matter where I look, up and down the stack, across different OSes and tech stacks, there are bugs. I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. The software I’ve written for myself or where I’ve taken the time to do things better or rewrite parts I wasn’t happy with have had remarkably few bugs. I have critical software still running—unmodified—at former employers which hasn’t been touched in nearly a decade. Perhaps not totally bug-free, but close enough that they haven’t been noticed or mattered enough to bother pushing a fix and cutting a release. Personally I think it’s clear we have the tools and capabilities to write software with one or two orders of magnitude fewer bugs than we choose to. If anything, my hope for AI-coded software development is that it drops the marginal cost difference between writing crap and writing good software, rebalancing the economic calculus in favor of quality for once.

dylan604 6mo ago
> I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. Blame PMs for this. Delivering by some arbitrary date on a calendar means that something is getting shipped regardless of quality. Make it functional for 80% of use, then we'll fix the remaining bits in releases. However, that doesn't happen as the team is assigned new task because new tasks/features is what brings in new users, not fixing existing problems.
- grvdrm 6mo ago
  I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”
  - dylan604 6mo ago
    Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.
    - grvdrm 6mo ago
      3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”
      - DrewADesign 6mo ago
        The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks that I thought I’d solve in a few days that took me weeks because I couldn’t foresee some series of problems to overcome. Taking a guess and adding time to it just shifts the endpoint of the guess. That didn’t help us much.
        grvdrm 6mo ago
        That's the point I am making, and the point of asking "what is the alternative" Developers aren't alone in adhering to schedules. Many folks in many roles do it. All deal with missed deadlines, success, expectation management, etc. No one operates in magical no-timeline land unless they do not at all answer to anyone or any user. Not the predominant model, right? So rather than just say "you can blame the PMs" I'd love to hear a realistic-to-business flow idea. I am not saying I have the answers or a "take". I've both asked for and been asked for estimates and many times told people "I can't estimate that because I don't know what will happen along the way." So, it's not just PMs. It's the whole system. Is there a real solution or are we pretending there might be? Honest inquiry.
        dylan604 6mo ago
        Software release dates are so arbitrary though. We no longer make physical media that needs time to make and ship. Why does software need to be released on February 15th instead of March 7th?
  - stouset 6mo ago
    “The alternative is that nothing will ever get released because devs will take forever making it perfect” is a really lame take. We have literally countless examples of software that devs have released entirely of their own volition when they felt it was ready. If anything, in my experience, software that’s written a little slower and to a higher standard of quality is faster-releasing in the long (and medium) run. You’d be shocked at how productive your developers are when they aren’t task-switching every thirty minutes to put out fires, or when feature work isn’t constantly burdened by having to upend unrelated parts of the code due to hopelessly interwoven design.
    - grvdrm 6mo ago
      I'm happy to be reoriented with examples. Please provide some? You said countless but mentioned none.
      - mrgoldenbrown 6mo ago
        tex was pretty bug free.
      - usefulcat 6mo ago
        I'd say SQLite is one good example: https://sqlite.org/chronology.html https://sqlite.org/chronology.html Regular releases for over a quarter of a century now, and it's renowned for its reliability.
  - noisy_boy 6mo ago
    I think PMs fail to understand categories of change in terms of complexity because they focus on the user facing surface and deal in timelines. A change that brings in a big feature can be straightforward because it perfectly fits the existing landscape. A seemingly trivial change can have lot of complexities that are hard to predict in terms of timelines. There is also the angle of asking for estimate without allocating time for estimation itself. For lack of a better word, I think it should drive from "complexity". Hardness of estimate should be inversely proportional to the complexity. Adding field to a UI when it is also exposed via the API is generally low complexity so my estimate would likely hold. We can provide estimate for a major change but the estimate would be soft and subject to stretch and it is the role of the PM to communicate it accordingly to the stakeholders.
- xp84 6mo ago
  Hearty agree. I think the PMs fall victim to wildly optimistic imagination of how fast and easy it will be to correct from “good enough to not get yelled at by CEO for not shipping by X date” to “works correctly and isn’t creating more bugs” - and importantly, it seems like they repeat this mistake every project, compounding the problem. So we perpetually have an increasing number of hacks, interacting with each other to cause difficult issues, all of which the PM says we will fix next sprint, just as soon as we ship one more Important Feature. Not all orgs of course. But most I’ve personally seen, seem to be like this.

by stouset 6mo ago

dylan604 6mo ago

> I’m not sure I’d go quite as far as GP, but they did caveat that we often choose not to write software with few bugs. And empirically, that’s pretty true. Blame PMs for this. Delivering by some arbitrary date on a calendar means that something is getting shipped regardless of quality. Make it functional for 80% of use, then we'll fix the remaining bits in releases. However, that doesn't happen as the team is assigned new task because new tasks/features is what brings in new users, not fixing existing problems.

grvdrm 6mo ago
I don’t disagree but is the alternative unbounded dev where you write code until it’s perfect? That doesn’t sound like a better business outcome. The trade off can’t be “take as long as you want”
- dylan604 6mo ago
  Some coding doesn't fit your schedule. If you've scheduled 2 weeks, but it takes 3, then it takes 3. Scheduling it to take 2 does nothing to actually make the coding faster.
  - grvdrm 6mo ago
    3 sounds fine. Then I ask: why not add a week to how long that thing will take, meaning it stretches two sprints (or whatever you call it). Add upfront. Then if you get to hard convo where someone says “do it sooner” you say “not possible.”
    - DrewADesign 6mo ago
      The fundamental problem remains: it’s difficult to predict how long it will take to solve a series of puzzles. I worked in a dev group where we’d take the happy path estimate and double it… it didn’t help much. So often I’d think something would take me a week, so two walls was allotted, but I made a discovery in my first like hour/day whatever that reduced the dev time to like a couple days. Then, there were tasks that I thought I’d solve in a few days that took me weeks because I couldn’t foresee some series of problems to overcome. Taking a guess and adding time to it just shifts the endpoint of the guess. That didn’t help us much.
      - grvdrm 6mo ago
        That's the point I am making, and the point of asking "what is the alternative" Developers aren't alone in adhering to schedules. Many folks in many roles do it. All deal with missed deadlines, success, expectation management, etc. No one operates in magical no-timeline land unless they do not at all answer to anyone or any user. Not the predominant model, right? So rather than just say "you can blame the PMs" I'd love to hear a realistic-to-business flow idea. I am not saying I have the answers or a "take". I've both asked for and been asked for estimates and many times told people "I can't estimate that because I don't know what will happen along the way." So, it's not just PMs. It's the whole system. Is there a real solution or are we pretending there might be? Honest inquiry.
        dylan604 6mo ago
        Software release dates are so arbitrary though. We no longer make physical media that needs time to make and ship. Why does software need to be released on February 15th instead of March 7th?
- stouset 6mo ago
  “The alternative is that nothing will ever get released because devs will take forever making it perfect” is a really lame take. We have literally countless examples of software that devs have released entirely of their own volition when they felt it was ready. If anything, in my experience, software that’s written a little slower and to a higher standard of quality is faster-releasing in the long (and medium) run. You’d be shocked at how productive your developers are when they aren’t task-switching every thirty minutes to put out fires, or when feature work isn’t constantly burdened by having to upend unrelated parts of the code due to hopelessly interwoven design.
  - grvdrm 6mo ago
    I'm happy to be reoriented with examples. Please provide some? You said countless but mentioned none.
    - mrgoldenbrown 6mo ago
      tex was pretty bug free.
    - usefulcat 6mo ago
      I'd say SQLite is one good example: https://sqlite.org/chronology.html https://sqlite.org/chronology.html Regular releases for over a quarter of a century now, and it's renowned for its reliability.
- noisy_boy 6mo ago
  I think PMs fail to understand categories of change in terms of complexity because they focus on the user facing surface and deal in timelines. A change that brings in a big feature can be straightforward because it perfectly fits the existing landscape. A seemingly trivial change can have lot of complexities that are hard to predict in terms of timelines. There is also the angle of asking for estimate without allocating time for estimation itself. For lack of a better word, I think it should drive from "complexity". Hardness of estimate should be inversely proportional to the complexity. Adding field to a UI when it is also exposed via the API is generally low complexity so my estimate would likely hold. We can provide estimate for a major change but the estimate would be soft and subject to stretch and it is the role of the PM to communicate it accordingly to the stakeholders.
xp84 6mo ago
Hearty agree. I think the PMs fall victim to wildly optimistic imagination of how fast and easy it will be to correct from “good enough to not get yelled at by CEO for not shipping by X date” to “works correctly and isn’t creating more bugs” - and importantly, it seems like they repeat this mistake every project, compounding the problem. So we perpetually have an increasing number of hacks, interacting with each other to cause difficult issues, all of which the PM says we will fix next sprint, just as soon as we ship one more Important Feature. Not all orgs of course. But most I’ve personally seen, seem to be like this.