alt Hacker News> 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.
Replies
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.
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”