I’m a software developer working for a finance firm of about 50 employees, 15 of which developers. I joined the company less than one year ago on a contract. I’ve recently been praised for my performance, promoted to a senior role, given a permanent position.

When I joined the company I was working in the R&D department. The project I worked on was delivered on time and under budget. In developing the project I was given a lot of freedom, so I tried to develop it from scratch following the best practices I knew from my software engineering book readings, such as code coverage, continuous refactoring, etc. The project has been praised and I’ve been told it’s going to be used as an example on how to write projects in the company (that’s not to brag, just to give context).

After I finished the project, I’ve been moved to another department as R&D didn’t have anything going on. The project I’ve been working on since then is a consultancy project. Saying it’s a mess, is not enough. It was failing once, and it’s currently one year and a half late on the delivery.

The management has been given an ultimatum of six months to deliver the project. In this situation, code quality is sacrificed to speed, and to make things more interesting timeliness in respecting the estimates have become part of our KPIs.

On top of that I’m the only developer working in this branch of the company, all the other developers are in a different city. So collaboration is not always the best. I’m also new to a very messy project so it takes me a while every time I work on a different part of the project to understand how things work. Result is, after two weeks, also due to an incorrect estimate, I am already late on my tasks, and I’m almost burning out trying to catchup with deadlines.

I’ve always thought that, despite the fact that the estimates are decided by the team of developers (with a small contribution from myself at the moment, considering I’m very new to the tasks involved in the project), they are still estimates, not really prone to accuracy.

How fair is it in this scenario that timeliness is part of my KPIs?

What would you guys do in my position to simplify your life and getting back to appreciating your job again?

  • 3
    VTC: half rant, half "what would you do?". Both are off-topic here. Note that it is incredibly common for software developers to be expected to deliver their code by specific deadlines, which are by definition estimates. If you miss deadlines then you need to be able to explain why the estimate was wrong and it sounds like you're forgetting that part of it. – Lilienthal Sep 14 '16 at 9:48

How fair is it in this scenario that timeliness is part of my KPIs?

It's not fair, but unfortunately it's not unusual either.

What would you guys do in my position

You've already been told what to do.

You were told that "code quality is sacrificed to speed". So

  • Sacrifice quality
  • Try to get as many features cut as you can
  • Deliver some code on time
  • Carry a lot of "tech debt" for version 2.0

While this is going on, decide if this is the way you want to work, or not. If the latter, update your resume, tune up your professional network, and start looking for a job in a place that better fits your personal and professional needs.

| improve this answer | |
  • 4
    It is always counterproductive to worry about whether something is fair; the workplace is not fair, it is not intended to be fair and it is not even possible to be fair (as fair as defined by one person often means unfair to another). @Jimmy, you need to stop concentrating on fair and start dealing with reality. – HLGEM Sep 14 '16 at 13:40
  • @HLGEM - I agree. "Fair" isn't a word I use at work. – WorkerDrone Sep 19 '16 at 14:15

I would agree that estimates are indeed estimates, not deadlines. But if the company wants to treat your estimates like KPIs, the only reasonable suggestion seems to be for you to treat your estimates like KPIs.

And that means padding them like crazy to make sure you can do the work in that time. You'll have to change your estimates from "I can probably fix this in two days" to "I will definitely have this done in six days."

Developers set estimates as a sort of lower where, on average over a lot of tasks, the majority of them will roughly take that long. That's because estimates are a planning tool. If you can say that if you deliver 5 slightly faster, 4 on time, and 1 a lot slower, on average you took about as much time as you initially estimated for all 10 of them. This lets project managers set up a broad timeline and have a fairly good idea of what will be done when, even if specific tasks might turn out to take longer.

In this way they are very useful. But if you look to specific tasks and start holding developers to finishing them in the estimated time, then you need to change the way you determine the estimated time. You can no longer say "We can fix 80% of features in this time, and in the time we save from the ones that are done faster, we'll handle the 20% that turn out to be bigger than we taught."

You'll have to say instead "We can finish 100% of features in this time." And that means you'll need to take the absolute worst case scenario for each and every issue. Every potential problem will need to increase the estimate by whatever time it would take you to solve it, since you can't rely on the rule of averages anymore.

Of course, you'll want to inform your team and your managers about this. It will have a profound impact on the project's planning because:

1) The deadline is going to be flying back by months, if not years by doing this 2) All estimates will be effectively useless for their original purpose of allowing management to plan a project in broad strokes

This is of course assuming that management and team don't want to rethink your approach halfway through informing them. That's why it's so important to let them know why you are going to be increasing your estimates in order to ensure you meet the KPIs.

| improve this answer | |
  • I would also add that many dev only consider actual dev time when doing estimates which means they will miss the deadline 100% of the time. Be sure to include time for communication and meetings, responding to issues raised by QA, doing deployments and immediate support after deployment, unavoidable delay, writing documentation, writing tests, fixing stuff as a result of the tests, etc. – HLGEM Sep 14 '16 at 13:44

First half of your job was a good trip you had, the second part is a bad one. Both are part of your job. There are good and bad times in every profession. So, learn to deal with it. If timeliness is a KPI, you need to follow it. It might not be completely fair to you, as you have taken the job midway in its not-so-good condition, but believe me, there is lot more to come in future. That's how you get most of the projects working.

You have had a good start of your career, just consider this one as your first professional hurdle. Prioritize timeliness and finish it up as soon as possible. Keep rising against the odds.

| improve this answer | |
  • Just to clarify: The advice here is to suck it up, and work extra hours to meet the estimate-driven deadlines? – Neil Slater Sep 14 '16 at 9:37
  • OP did not mentioned anything about working extra hours. But in case if required, one needs to do whatever it takes. A developer doesn't just work on a project, he owns it. – Techidiot Sep 14 '16 at 9:41
  • 1
    From OP: "Result is, after two weeks, also due to an incorrect estimate, I am already late on my tasks, and I’m almost burning out trying to catchup with deadlines." - I am assuming that reference to burn-out is extra work. A senior dev can also "own" a project, but that includes owning the planning process, not being a slave to it - it does not seem possible in this case for the dev to "own" a project where he is not also owning the estimates. – Neil Slater Sep 14 '16 at 9:44
  • Yes. And that's how one learns. It takes time initially to get adjusted to these things. He can neither just drop it out, or can ask for some help. So, its better to hold on to the nerves and keep working. 2 weeks is not a time spam for giving up on anything I guess. – Techidiot Sep 14 '16 at 9:49

Not the answer you're looking for? Browse other questions tagged .