I have been working as a Jr. Developer at my current job for about a year and half. After been at my job for about 5 months I volunteered to do complete rewrite of a very old system that the company had. At the time I said I would do it I was confident it would take a few months at the most, but it has now been over a year since I started to work on the projected and it has proved to be much much harder then I expected.

I just had my review for the 2013 year and it was mentioned that this project is running much longer then I had stated. The biggest things that have caused the project to run long is that I had to learn a whole new coding style (I knew this going in) and I am required to use a framework that was developed in house and is way above my ability to understand and build off of.

Looking at this project now I am fairly confident I can no longer complete it within the extra time given to me (it is now one of my 2014 goal to complete the project). How do I best explain to my boss that I don't think I can complete this project in any decent amount of time and that I should no longer be the developer for this project?

EDIT: Everyone is assuming that I saw this project as a failed project within months of starting it, that is NOT THE CASE. I know the project was going to be hard but I thought I could handle it. Every time I hit a wall in the project and I was able to over come it I thought I could keep going. It has only been over the past few days I have come the realization there are too many walls left and I don't have the skill to do this project.

  • 8
    With this, the sooner you come clean, the better. Since it's been more than a year, this is going to be ugly no matter how it goes. Putting it off any longer isn't helping. Apr 2, 2014 at 18:38
  • It has only been over the past few days that I have allowed my self to realize the truth and want to come clean very soon but I have no idea how best to do this with out making things worse and possibly getting fired. Apr 2, 2014 at 18:44
  • A little late to the discussion, but this kind of situation is actually not yours, but your management mistake. If you said it'd take 2 months after say 3 months your boss should have done something about it.
    – ren
    Apr 11, 2014 at 14:13
  • 2
    @ren I don't know which is the worst management failure - giving the go-ahead for a rewrite, giving it to a junior, or not asking for any updates in way too long. The tl;dr of rewrites is: DON'T. joelonsoftware.com/articles/fog0000000069.html Dec 9, 2014 at 13:23

6 Answers 6


Some questions that you'll need to be prepared to answer:

- What have you been doing all this time?

Be prepared to show work and discuss hurdles that you have been unable to jump over to accomplish the job.

- What do we have if we stop now? Is any of this salvageable?

Hopefully so. If you have part of the system working, show it, as that can take some of the sting away.

- Why didn't you come to me sooner?

This one is going to be hard to answer. As a junior developer, you probably were blinded by hubris. Most projects' estimates come in under their actual completion time. This has gone from months to years, so some big explanations will be necessary.

The bottom line is your boss won't be happy with this, but you're a junior dev, so mistakes are expected. You need to fess up to them a lot sooner in the future. I don't think it's a fireable offense, but it may be a write-up or some sort of verbal warning. Good luck.

  • Thanks for the suggestions, based off these and some Google results I have been building a little "letter" that will help me when I approach my boss about this. Apr 2, 2014 at 20:26

In addition to Garrison Neely's excellent answer, I'd advise that how you say this is almost as important as the fact that you say it.

Instead of something like I failed; I can't complete this project, try framing it more positively - something like I'm hitting a wall, and need some help from a more senior resource to get past it. In addition to allowing you to potentially salvage success here, it serves a dual purpose in explaining why you're behind schedule, as well as proposing a solution to that very problem.

  • This is along the lines of what I was thinking. Often when I find myself hitting walls, having that senior resource is huge benefit and an hour of their time can save me weeks.
    – emragins
    Apr 5, 2014 at 17:46
  • 2
    Definitely. No matter how junior or senior you are, there's no shame in asking for help.
    – Mike
    Apr 6, 2014 at 0:07

I second anyone who tells you that you need to tell your boss ASAP.

  • Give an unadorned status report on the project but don't just say you failed - such a succinct assessment would stick to you like indelible black ink on a white shirt.
  • Start your status report by saying that the project is behind the schedule you had worked out, then go over the parts that went well and the parts that didn't go well.
  • Don't just go over the parts that didn't go well, because if you do, you will give people a distorted perception of your abilities and your efforts. Let them work out what they want to do next.
  • Lastly, Cut out the volunteering for anything for a while.
  • 5
    Not voting on this one, but it's a good answer with a little unnecessary brow-beating in there. I think the asker knows s/he's in a pile of crap. We don't need to heap on more judgement. Apr 2, 2014 at 19:22
  • 2
    @GarrisonNeely Thanks, this does seem more of just brow-beating me, expecialy since incorrect assumtions are made and some wrong "facts" pointed out (i.e. I only missed the first deadline of 3 months, the second deadline is EOY 2014). then actually trying to address my original question of looking for advice on how to address this with my boss. I do like the advice of giving an unadorned status report, though. Apr 2, 2014 at 19:26
  • 3
    I've made a substantial edit to this to cut out the brow-beating. That part doesn't really answer the question and put the answer in danger of deletion. You're always free to edit further if you could think about whether there's a better way to say it. Thanks. Apr 3, 2014 at 1:58
  • 4
    Hi Vietnhi, please remember the goal of our site is to provide helpful answers to the question. Focusing on merely pointing out a person's flaws doesn't help them nearly as much as answers that constructively explain how to improve. When answering, focus on positive solutions. Good luck!
    – jmort253
    Apr 3, 2014 at 2:10

As you are a junior developer, treat this as a learning opportunity. One of the things that a junior is usually not expected to be able to do is to oversee the scope and consequences of tackling a large project as the one you are involved in.

The best course of action now is to schedule a meeting with your direct supervisor and admit to him that you are in over your head with your project and that you would like some guidance in how to proceed. You can expect some tough questions, like the ones in the answer from @GarrisonNeely, but the most important thing when answering them is to tell the truth and not to try to make things look better than they are.

If you have a good manager, admitting that you are in over your head as a junior developer is not necessarily a bad thing. It is possible that your manager already knew that you wouldn't be able to complete the project by the new deadline and is waiting for you to step over your pride and admit failure yourself. I would value that more than having to forcefully pull someone from their task because it has become obvious that they can't handle it (yet).

As for the future of the project, it can go in several directions.

  • It can be dropped altogether, especially if the project wasn't that important to the organization in the first place
  • It can be reassigned to someone else, with you getting a job that is a better fit to your current capabilities
  • You can get additional, more senior, developers assigned to the project to help you out.

If you are planning to bail out, present argumentation why you are need to do so. If your plan stretched that far, you need to have strong arguments. In this case, prepare a project plan for the upcoming, say, 6 months of work, and prove that none of those work was anticipated when you started. Give as much information is possible. Include why it's been over a year, and what extra/unexpected work has been completed to date.

Once you have an overview of your past performance, as well as your future expectations of yourself, you can present this to a manager with something like "According to my observations, this is taking longer than expected. Here are my findings. Due to this reason and this reason (put some strong arguments here), it may even take longer than that. Should I continue working on this project?" With this, you are effectively saying, "Yes, it's taking longer than expected, but I kind of know where I am going, and where I went wrong in the past, but I also let you, the manager decide the outcome". Managers like to decide, so you get a +1 here right away.

For future projects (I am assuming you are not gonna drop development work just cause you failed once), never take on something you perceive as complicated. Chances are you will either never complete it (like this one), or it will take longer than expected and the benefits will not be worth it (from the management's perspective).

Instead, take work that you find super simple (and achievable in less than a day). It will often end up stretching 4-5 days, so you will learn how to estimate, but also the company would not lose as much money on you. Fail fast, and often. Remember, you learn from your mistakes, not your successes.

If there is no small work, try to break down the work you have into small self-sufficient pieces, i.e. each one should have a value and stand on their own. You need to estimate your work before you start it. I.e. never have something like "well, it's a research task, so it's gonna take 2 weeks, maybe a month..." Know the area, know the questions are going to solve.

If you don't know what exactly you are researching, don't commit to a time frame, say "I need 1 day to build a project plan for my research, I'll provide an estimate then". Use this time to get a better understanding of your problem.

If you cannot make an estimate on a task, you don't know what you are doing. Don't start a task, if this is the case. Get more information, until you are absolutely confident it will take X days. Sometimes it helps to use your past experiences, i.e. "this should take 1 day, but a similar task 3 months ago took 5 days, maybe I am missing something..."


It sounds like you are including some assessments you are not qualified to make, such as "[the framework] is way above my ability to understand" and "I should no longer be the developer for the project". These assessments will require your boss to do some extra digging to find out what actually happened, what should have happened, and what should be done now.

Rather than focus on such assessments, your focus should be to provide your boss with specific factual details about the project, including specific limits of your understanding. For example, "I worked for 3 months on rewriting the login component. By this time it was supposed to interface with LDAP, and it still doesn't. It does statefully track login attempts. Since I don't understand the LDAP hash protocol, I don't know whether the code I wrote can be adjusted to interface with LDAP, or whether it requires a totally different approach. ..."

You must log in to answer this question.

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