When a developer’s estimate is “too high”, the product manager and developer work together to determine what can be accomplished in an acceptable time-frame. Balancing need with practicality.

You wouldn’t pay a carpenter who ignored the plans and built what he wanted to build. And I remember my own food-service experiences in high school and college – the expectation was that you stuck to the recipe. If you thought you had a better recipe, you worked to get that changed – you did NOT just do it your own way.

I agree with rick, part of the problem come from how expectations are set for developer. There was a time where a good developer was the one who align 70 hours a week. After some evolution we ended up with the good developer being the one who are close to or on budget. The feature of the requirement was, and often still is, assume to be satisfied. It’s like if it’s obvious: the developer worked on the requirement and job is done, so requirement is satisfy. Simple. But how many projects have its requirements partially satisfy: most of them.

It’s that the requirement satisfaction must be the first element to take into account. Budget and delivery time is very important…but second to requirement satisfaction. At McDonald, I’m sure you can be fired for serving a Big Mac that does not taste ‘Big Mac’. On the other side, if you are expected to deliver it in 5.5 minutes to drive-thru, you may not be fired for making it in 7 or 8 minutes. They will train you and give you some tricks to improve the delivery time or worst but you’ll have a chance.

I think software should also be like this: first, deliver a requirement that taste as expected. But it’s not just the responsibility of the developer. Project management, design, QA etc.. must all be aligned on the same and ultimate measure of success: working software that satisfy the requirement.

Now, I’m not advocating that developers be fired the first time they ignore a spec… and the spec certainly has to make sense, etc. But if the spec has been done well, with customer input and internal input then you cannot allow developers to ignore it or do what they want simply isn’t tenable. Sure, allow feedback, be willing to incorporate new ideas… but that the end of the day, developers need to understand that they’re part of the team. For too long most companies have reinforced the message that developers are special and tolerated things that we’d not tolerate from other other skilled professionals. If a developer persistently ignores the spec or implements things that they think would be cool but that aren’t in the spec they need to be disciplined. If they keep it up, they should be fired – just as you’d fire a sales person who didn’t sell, an accountant who wouldn’t balance the books or a program manager who refused to track project details.