Why are deadlines always so short? [duplicate]

Question

I'm a junior developer in a small company (in a team of 2 developers). Everytime we are asked to implement a new feature:

• the deadline is set so that we just have time to do the development: there is no error margin (if something takes a little bit more time than expected, we are late) ; almost no time for tests (we are pretty sure there will be bugs) ; no time to refactor anything

• we are asked to start the development before the features are completely specified, so new things to do show up but the deadline stays as it is

The result is that we deliver software that has bugs and the technical debt keeps growing. We use technology that was considered as a recent version in 2006 or so.

There was one release that I remember very well. When we did a demonstration to the boss, he told us "What!?? You took two weeks to produce that?!" and all we could answer was "No, in fact it took us three weeks". I had a meeting with him and another junior developer (that quit the company because of this said meeting!), and he basically told us that he was not happy because what we released was crap.

The technical debt and the need to refactor were so big in the parts that we had to modify (but we were told not to refactor because we have no time) that:

• we had to add a layer of bad code on top of the already bad code;
• we took much time to try and understand completely incomprehensible code.

I don't feel like I'm responsible for this bad release, I think that it's the boss' responsibility to hire good developers that, at least, understand the basic principles of OOP. But hiring juniors is so much less expensive...

He is already saying that we are late for the development I'm working on at the moment. He spent more than one year to "redesign" a tool that was already present in our application, but now he wants us to implement it in two weeks. I personally think that if we want to do it correctly, we need at least one month, or maybe even 6 weeks.

I don't know what to do, because I think that the boss thinks that we are just slow and ineffective. That's not the way I will get the raise I think I deserve.

Why is it like that? That doesn't seem so hard to understand that if I need x days to complete a task, I can't do it in x/2 days, even if you say "please" and ask with a smile. That seems so obvious that the deadline will be missed and/or that the quality requirements won't be met.

I don't need to know how I can explain to my boss that software development is a longer process that just clicking an icon. Because I hope he already knows that.

Answer 1

Two choices really: Quit, or grow a backbone.

I think I don't have to explain much about quitting.. that one is obvious. If you can neither take it nor dare to change it, it's the only way to go forward.

If you do want to change this, then it is your responsibility to stand up against this. This does need "a backbone", because you will be going against your boss and being fired is a real possibility there! So tread with caution, but stop being pushed around.

Why am I saying that you're pushed around? Well, of course, junior devs are easier to push around than seniors, because they lack experience, but, there is one fundamental issue you seem to totally have missed here (which got pushed past you so to say) : Deadlines are best made by the developers, not by management.

If your boss or some manager says it takes 2 weeks and you think that is is too short, then professional behavior dictates that you inform your superiors of this insight. After all, you are the developer who is going to spend those 2 weeks doing the work. There is no one - absolutely no one - who is more qualified to judge the correctness of this estimate than you! Your managers may resort to prior experience or other teams' performances, but you know the real deal. You know the particular code base, its weaknesses, its risks, etc. There is no way that any meaningful deadline can be made without your input.

Refactoring: This is an interesting topic always and there are many good reads on how to incorporate it into a schedule. The gist of these though is that a) you will never ever get time dedicated for refactoring from your manager and b) you shouldn't even ask for that, because even when you get it, it'll not be enough. Refactoring is something that must become part of your every day work. It must be part of your estimates, and it is part of what you are doing. So much that you need not even mention it towards management. This is how we work professionally after all. You may skip it once or twice remarking that the next deadlines need to account for that, but if you cannot make it up, then the professional way is to get it done right the first time. Of course, you have to keep a balance and not refactor the whole code base first for half a year. Stick to what you are working on anyways and try to keep the technical debt instead of increasing it, if possible even reduce it a little.

When a deadline approaches - in particular if the deadline was given to you from outside sources without your approval - it is fair game to simply tell them that you are not done. If you said from the start that 2 weeks will not be enough, then no one can blame you for not being finished after 2 weeks. The way from junior to senior dev means learning to be able to keep a straight face when telling your managers that it is not done due to their decisions. Keep in mind that if you estimated 4 weeks, but were required to deliver within 2 weeks, that any delay is not your fault.

Nevertheless, managers will try to blame you / your team for any delays. If you want to keep going with this company, then you face an even tougher challenge: you have to change your managers mind! You have to remind them that it is not about assigning blame, but about providing value to the business. You are supposed to work together, not against each others, but from what you tell it seems that there is a big trust problem between developers and management. Standing up against ridiculous deadlines is one thing, but it will only get you so far. If you have to constantly fight your managers, then you are bound to fail (both sides actually).

In summary, if you believe you are strong enough and can keep up with the pressure and stress, then you should 1) ensure you are part of the deadline decision from the beginning and 2) improve confidence and trust between developers and managers. The first is comparatively quick and easy, whereas the latter is a slow and delicate process that may well take you years.

Answer 2

There are a lot of reasons why deadlines will always be tight.

One of the main theories here is Parkinson's law.

Parkinson states: "Work expands so as to fill the time available for its completion".

So, if you have a project that would take 3 months and you get a 6 month deadline? How long would it take? 6 Months of course, because there's always something that can be improved.

By setting tighter deadlines, management tries to bring out the best in people. The power of tight deadlines.

There are a lot of reasons to set tight deadlines, some good, some bad. There are also a lot of good and bad managers, who do or don't understand management theory.

Answer 3

"Growing balls" was mentioned, but that's mostly a problem of the manager, who has pressure from above and lets himself being talked into promises that he cannot keep. At my workplace things got improved a lot when my manager's manager, who never managed to get the results he promised, was replaced. The new manager was given a list of 10 things to achieve, and he just said "no" to seven of them. And didn't budge one bit from the seven "no's" no matter how they tried to pressure him. And then the teams under him, without ridiculous deadlines, achieved the three tasks he had accepted. Which the previous manager would have failed to do. Everyone (up and down) is really happy with him.

What bad deadline setting achieves is: Pointless stress, drop in productivity, feeling bad because everyone fails, possibly rushed and low quality products.

What you can achieve with deadlines: Change priorities so that some tasks will be finished. For example, if job A looks like it will be 90% finished, and job B looks like it will be 60% finished, you move effort from B to A so that one of them will be done within the deadline. Or reduce the scope of a job. If job A with all planned features cannot be achieved in the deadline, you reduce the features.

About estimates: If you make a best estimate for the time a task takes, and you are really, really good, then the task will take the estimated time, plus or minus some random extra time. That's why it is called a "best estimate". If you make an estimate, nobody can change that. Never allow anyone to make you change your estimates (unless they first reduce the task that is estimated). Your manager then can set targets. If these targets don't agree with the estimates, that's his fault. If you estimate "it takes three months" and he says "do it in two weeks", it's his fault if you don't finish in two weeks. It's even more his fault if he stresses you out and you don't even finish in the estimated three months.

Answer 4

Why are deadlines always so short ?

Because managers like the one in your story hijack the estimation process and impose their own views onto developers. Oftentimes this is because they are former developers themselves and think they can come up with good estimates thanks to their experience.

In an ideal world, managers would trust programmers and let them take responsibility for producing estimates, like you'd do with any self-respecting professional. Client-defined deadlines would be met not by deteriorating quality but negotiating scope with the client.

Answer 5

Your team clearly suffers from Overly optimistic schedules :

The challenges faced by someone building a three-month application are quite different than the challenges faced by someone building a one-year application. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hurts developer morale and productivity.

If you are really working hard, then it is the problem of the management.

is it always like that? Are the deadlines always short?

My experience is : yes, they usually are. But if the plan is too optimistic, then it is doomed for failure.

is there something I can do about it?

Nowhere you said that you are involved in the schedule planning, which is really weird. I guess, this is so, because you are still a junior developer. Even then, they should ask you.

The only reasonable answer is to plan properly. How long will design, development, and refactoring take? Give best, most likely and worse estimates, and present them to your manager. What is important is not to back up from your estimates, and not allow negotiations about them (see this).

Answer 6

When we submit a man-year estimate, that number is determined by a gut-feeling based on experience, on guessing at the risks of new tools, new problems, etc. Normally we get it about right, but we can't justify this. In the old days, when man-years grew on trees, our bosses, who were ex-softies themselves, trusted us, we got those hours given and off we went.

Since then two things happened; budgets got slashed and management courses were invented as a cheap substitute for engineering.

So now we have bosses who are under immense pressure to cut costs, because the competition has cut costs too, and these very people have little or no technical background. So if you say 5 man-years, he will say, well, I'll give you 4, because that works for him when he gets a plumber in. Now good, we know that cheap and hasty plumbing means leaks in the future, but by then he will have moved house, or in the manager's case gone off to a better-paid job in another branch.

But it's not always that bad. You have an extreme case, and that firm is going to go belly up sometime, so think seriously about finding a new job.

Answer 7

One issue I've seen a few times is that the PHBs don't quite get that the first working version of a product is far from done -- they can't see that it is still really a rough draft.

Nowadays I ask them "so, when you write a proposal do you get it complete and send it to the client or do you go through a drafting process?"

Refactoring is our drafting process.

Answer 8

Deadlines are always too short because the estimates are inaccurate.

There are two important points to consider with deadlines:

1. Estimates must be based on all expected effort (including understanding, implementing, testing new/previous behaviour, and deployment, and more)
2. Sometimes estimates are wrong

Point 1 speaks for itself as estimates must reflect the work that's required, and at the speed of the person(s) doing the work.

Point 2 however acknowledges that whilst estimates may improve over time, and the typical Scotty Principle should apply, there is always the chance that the estimate is just plain wrong.

It is up to the whole team (everyone including the manager) to accept that deadlines being too short indicates a problem in the estimations.

Your case indicates that the problem could be that your deadlines are given to you without proper investigation into the level of effort required (i.e. asking you how long it would take to do the work).

Sometimes the deadline is immovable e.g. releasing before date X means you all get paid, whilst after means no one buys/pays for the work; here everyone must accept that there isn't time to get the work done as completely as it could be.

Lastly, there could potentially be a trust issue where the manager has been burned in the past by work being overestimated; if you deliver early and report this to your manager you will build trust and the team attitude will improve.

Decide how much effort to put into this; if it still isn't working decide to move on to another team/company.

Just be aware that this scenario is not limited to this specific manager, at this specific company, and the sooner you determine your way of handling this the better you will be.

Answer 9

I believe the primary reason deadlines are often too tight comes from a profound misunderstanding.

There are several variables to juggle when producing something:

• effort: the necessary duration to be spent to produce
• elapsed: the duration between beginning and finishing

The effort is non-negotiable, if it takes you 10 hours to accomplish a task there is nothing you can do about it. Another person might be able to do it either faster or slower, however. In Agile practices, the recommendation is to measure the effort in points to account for differences in velocity between developers.

The elapsed however, varies widely: it depends on how many people will be working on parallel, how many hours each day they will work on it, etc... In the end, therefore, the elapsed depends on planning: who will be affected to the task, when, ...

Often times, deadlines are negotiated. Because the elapsed depends a lot on planning (and shifting priorities), there is indeed some slack, and therefore they can be negotiated indeed to a degree. Bad managers, however, tend to impose unrealistic deadlines because they keep pushing them past that degree reasoning that since they managed to push it back some, they might as well try some more.

---

When this happens to you, and they keep pressuring you, you might be interesting in the Agile movement. Agile "cheated" by introducing a third variable: scope.

Instead of sizing the whole thing, you size it piecemeal (and make the dependencies between the pieces explicit). If your manager wishes to reduce the elapsed time, he may then remove some pieces.