Inability to say no and push back. I am guilty of it myself. Most experienced software developers know in their gut a lower bound for a project's timeline, whi

Inability to say no and push back. I am guilty of it myself. Most experienced software developers know in their gut a lower bound for a project's timeline, which always exceeds the timeline in managers' or PM's mind. When the VP asks how long a project will take, it is hard to not say something optimistic. Or when your release timeline is every six months, it is hard to say a project will take more than a release cycle. These are social issues more than technical. I know a mostly accurate and simple estimation approach, which is roughly the Pareto Principle: make a good effort to build a decent prototype and multiply the time it took by 4 to get to an estimate. But of course good luck selling this to your management! My advice to improve estimations would be around: - Building a prototype before making any estimations. Software is in a lucky position where you can build prototypes before the actual thing. - Applying the Pareto Principle, if you can. The reason for multiplying by 3-4 is because you have to account for research, design reviews, implementation, testing, bug fixes, documentation, and internationalization, etc.