The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification.
"They write the right stuff" about the shuttle software group is basically a story about doing that: https://www.fastcompany.com/28121/they-write-right-stuff
In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.
Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.
Good communication isn’t adversarial: by the time it becomes adversarial, you’ve already lost. It can include solid documentation, taking the time to mentor others, respectful but clear code reviews, helping others argue your case for rescoping, presenting your work at meet-ups or conferences, hallway testing a new feature, listening to teammates explain an approach…
…and yes, sometimes negotiating capacity. If that feels like an adversarial conversation, then your manager sucks, and you should find a new one.
Requirements and roadmaps are very different in my opinion. Requirements say what the product needs to do, scaling and/or response time targets, systems or needs to integrate with, etc. Roadmaps are either a high level plan for where the project goes in the future or a list of seemingly arbitrary deadlines.
Both have their place, but in my experience the right balance has been precise and complete specs with a high level, flexible roadmap.
I’d wager portraying an important work relationship as adverserial and manipulative is why people downvote you. It’s a bit of an overplayed cliché with the bad boss.
Ironically you might be downvoted because of what you’re saying being misunderstood, which I guess is to your point.
I've seen a project go from an empty repo to production in two months with a set of requirements that were completely unambiguous and rock solid. I've also seen ambiguous and vacillating requirements drag out the implementation a ~30 LOC feature for months.
I’ve also been a manager at 3 different companies, one of them my own, and my philosophy has not been to push deadlines or work, but to spend more time understanding requirements, and simply try to break down long-running projects into small pieces that can be estimated more accurately. One of the biggest problems I’ve witnessed in software is that estimates in units of years are always very wrong, while estimates in units of days or weeks are pretty good.
I have to agree with the parent; you’re making incorrect assumptions and maybe projecting your own bad experience, and ending up accidentally saying something that isn’t true.
If the requirements were actually precise and concrete, you could commit them to git and that would be the end of it.
The fact that they aren't is a sign of information deficit and this must be understood by all parties if we should have any chance of a productive outcome.
The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.
I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.
(this might not apply if you are writing code for moonships)