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.
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.
https://sqlite.org/chronology.html
Regular releases for over a quarter of a century now, and it's renowned for its reliability.
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.
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.”
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.
It's inevitable that work will slip. That doesn't necessarily mean the release will slip. Sometimes you actually need the thing, but often the work is something you want to include in the release but don't absolutely have to. Then you can decide which tradeoff you prefer, delaying the release or reducing its scope.
Earlier discussion focuses on writing software at a slower pace to inject more accuracy and robust thinking/design/code. Conceptually, yes, I get it!
But in numerous practical scenarios, some adherence to a recurring schedule seems like the only way to align software to business outcomes. My thinking is tied more to enterprise products (both external and internal) rather than open-source.
I like an active dialog with engineers. (I'm neither SWE nor PM). Let's talk together about estimates. What's possible and not possible. Where do you feel most uncertain, most certain. What dependencies/externalities do you expect to cause problems.
Those conversations help me (business/analytics-side) do things like adjust my own deadlines, schedules. Communicate with c-suite to realign on what's possible and not. Adjust time.
I feel for anyone that has to wrangle these tasks into a business-consumable time frame.
What a great articulation. Completely agree.
This is why I don't blame PMs anymore than devs anymore than business folks throwing requirements at PMs. Possible to find fault everywhere.
I think the broader problem is scale and growth. Many people in many roles are caught in growth-mind or scale-mind companies where the business wants to operate at a velocity that may not align with the realistic development work we're discussing. PMs are similarly caught with less time to understand, scope, plan, etc. Business folks ask questions like "why isn't this ready" to devs that may not understand the reasons why the business operates the way it does, or the business at all.
Full disclosure: I'm in insurance. Seeing lots of these problems play out in front of me. C-suite moving at speed 100, devs moving at a perceived speed of 50. Silos and communication problems and unclear requirements up and down the stack.
So, in my interactions, the way I try to help is just to understand the most basic components and their ability to come alive or not. Is there anything to show? Yes, ok - let's celebrate a small win. Is there a rather large delay? Why - ok, let's use that to reinforce building something robust vs. crap.
But, there are schedules! Someone above mentioned sqlite. Another example comes to mind: Obsidian. I think they're anomalies (good ones) rather than examples that broadly prove the point to slow down.
Because it has to be released at some point, and without picking a point in advance, you can never reach it.
Not all orgs of course. But most I’ve personally seen, seem to be like this.