Another reason to not do time estimates

Given a developer working on a task that is estimated to 8 hours
when she's close to running out of those hours
then she will take shortcuts to not exceed the 8 hours and care less about the code quality.

What, How and Why

When reading some other developers code I often think in terms of what, how and why. I start of with my what questions like:
- What is going on?
- What is it that are done?
- What is accomplished here?
These questions are always answered in the actual code, if it is written by a skilled developer then I find them the in the method names.
Next step is to find out "how" these "whats" are accomplished. This is the method bodies. Easy enough to find.

The last question I ask is "why" are these "whats" and "hows" here. This question is nearly never answered from the code (or at all). If I'm lucky some peer developer knows or there's a requirement specification document that, in best case are kept updated, gives the answer.

One solution to the "why"-problem are Executable specifications. Since specification motivates the existence of the code and if the specification itself is in code it will be really easy to connected it to the actual function. It will be trustworthy since I know it is kept updated.