alt Hacker News> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?
Also, work tends to expand to occupy alloted time. That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
So by not limiting what should be done in 60 days, they are more likely to avoid this pitfall.
Replies
I've found that people who do this have just told your company they are not worth the money to employ them, and they go in the next downsize. If the sixty days is enforced by being the actual deadline, all the important steps (documentation, testing, future-proofing, extensibility, simplicity of design, etc.) should be done, along with a new set of custom tools to make the same type of job take a week next time it is asked for. By somebody else if necessary. Ironically (?) the best developers build their own redundancy into their work. I developed in a way that allowed another person to get up to speed and take over my work. It informs good design, coding and documentation. I kept that job for over twenty years with several downsizing episodes. Sorry this sounds like gloating, but it was a technique that worked, so I thought I'd share.
> That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
This happens in mostly too situations:
- the person has absolutely no stakes in the game, and you are the only one caring whether it takes 60 days or not. Typically if you are paying them based on their hours worked as a contractor.
- The person understands that the task or the deadline is bullshit and nothing will important will happen whether it's finished in 60 days or not.
Either way, it's never a great situation IMHO.