Past: Start new job as software engineer out of college. Assigned an uncommented, undocumented, mess of a project with no training or mentors. I am the only person working on this project, nobody else knows or has ever seen the code at all.

I tell my manager that the code is very messed up and has bugs, but he tells me to work on features instead of fixing the code. Now months have passed and it is soon time to show program to client, and I am worried that I will be chastised for giving a partially "broken" program.

Since refactoring is not and never was an option due to time constraints and manager's wishes, what can I do to avoid my impending doom? I feel like I was unintentionally set up for failure from the very beginning. I even think that I made matters worse by adding features on top of the buggy code, since I had to do some weird things to bypass the bugs.

How can I avoid being chastised for a project I inherited which was already buggy, while I was told to work on more features instead of bug fixing?

EDIT: I feel like this is different than the question marked duplicate, as I am a brand new developer with 0 years experience. I feel like this is an important aspect of my situation.

  • Possible duplicate of How do you figure out if you're on a Death March?
    – gnat
    Commented Nov 1, 2016 at 19:07
  • Comments are not for extended discussion; this conversation has been moved to chat. Commented Nov 3, 2016 at 17:00
  • Ah, the poisoned chalice. I think I had this project for a bit.
    – Strawberry
    Commented Nov 4, 2016 at 13:05
  • @Simba Obligatory reference to Scotty.
    – employee-X
    Commented Nov 5, 2016 at 13:38
  • 5
    However well (or poorly) this goes, be thankful you learned the lesson early in your career, instead of later. This is not an uncommon situation and I see a lot of good advice here: if it happens again, you'll be prepared to handle it tactfully and professionally from the beginning of the relationship.
    – employee-X
    Commented Nov 5, 2016 at 13:46

12 Answers 12


You now know this piece of software better than anyone.

So, when it comes to the demonstration, concentrate on the parts that work well (or at least work as they should). Any other features that don't currently work that well can be labelled as "in progress" or "prototype". Use these to discuss how these features can be improved upon (or, even better, let them tell you that these aren't important).

Also, it would be a good idea to note down steps for the demonstration and run through the version of the program to be demonstrated beforehand so that you can note down anything which may go wrong. You can then say "this should ..." and before doing it in the demo say what may go wrong and that it is in your "to-do" queue to be fixed. That way you are not left going "umm.. umm.. that wasn't meant to happen."

Obviously, take a look at what you're demonstrating and know what works and what doesn't. Also look at any documentation/talk to people and understand what should work and how. Demonstrating knowledge and showing confidence in the system will engender confidence in you and what you say. This will help you get things back on the rails.

It's between you and your manager how you pitch your role in this - i.e. if you tell them that the original developer has left the project and that you've had to pick up the reins. People do tend to respect honesty more than dishonesty, and attempts to cover up for a previous developer will invariably be seen as covering up (and people don't like that).

Being up-front may reap benefits in allowing the project to be re-focused (previous developer may have led the project down an unwanted route anyway).

  • 13
    I think your answer best helps me in this situation, but I am a bit hesitant to use the "old developer left it..." line due to it maybe seeming like I am trying to blame someone else.
    – Prodnegel
    Commented Nov 1, 2016 at 16:08
  • 38
    @Prodnegel - Why? It's perfectly natural that staff move on. You can also term this as he got "taken off project", or "I'm now assigned to this project". There's no need for it to be blame based, it's just plain facts.
    – user44108
    Commented Nov 1, 2016 at 16:15
  • 9
    It's less about passing the blame as much as passing responsibility. I think it's better to say "I was tasked with adding x new features, which I will show you here." The other way it looks like "I was given this, found these, and decided not to fix them because they weren't my problem." The problem there is that to the customer if he is the developer on the project then they are his problem to an extent (really the manager's problem, but he is the representative in this case). Commented Nov 1, 2016 at 16:57
  • 34
    Also, it would be a good idea to note down steps for the demonstration and run through the version of the program to be demonstrated beforehand so that you can note down anything which may go wrong. You can then say "this should ..." and before doing it in the demo say what may go wrong and that it is in your "to-do" queue to be fixed. That way you are not left going "umm.. umm.. that wasn't meant to happen." Commented Nov 1, 2016 at 18:44
  • 14
    @AndrewMorton This is too good to be left in a comment. When you're making a demo, prepare the demo. Don't just wing it - plan it, rehearse it, fix or avoid any bugs you uncover this way, and do the performance. Think about what the customer is likely to ask or want to see, and figure out a good response. Walk through everything with your manager, so that you're both clear on exactly what you're delivering and what you/he need to be cautious of. Cut things that don't work well enough - a missing feature ("WIP") is often better than a horribly broken feature.
    – Luaan
    Commented Nov 2, 2016 at 12:00

In this sort of situation you need to cover your back. Always get it in writing what the issues are and especially the managers response to ignore them and add features. It's as simple as sending an email.

'Hello boss, further to our conversation, can you clarify what I should prioritise please. There's a bunch of bugs in X, or should I just go with the new stuff. Also I had to do some digital kung fu to get around a bug in W, it that ok?'

If your backs covered, it doesn't matter so much, the manager is in it, not you, you're just doing your job.

  • 5
    Why not? Workers don't go off on their own (hopefully). It's the managers responsibility to basically manage projects in terms of his team. I'd be more likely to sack the managers myself if it all fell to bits.
    – Kilisi
    Commented Nov 1, 2016 at 15:09
  • 9
    But even emails detailing the issues that are NOT replied to are still strong evidence.
    – Kilisi
    Commented Nov 1, 2016 at 15:10
  • 77
    @Prodnegel having 'quick conversations' is how many unscrupulous people try to do things under the radar. From now on in your career and every last time this happens, send a follow up email that starts with "As per our conversation" and detail what you were instructed. That is the only way to cover your backside when someone insists on talking to you "off line" Commented Nov 1, 2016 at 15:24
  • 36
    Not only is emailing a summary of the conversation a good way to CYA, it's also a valuable check that both parties have the same understanding of the issues. Commented Nov 1, 2016 at 15:29
  • 8
    I'd probably refrain from using phrasing like "digital kung-fu", particularly with managers who are non-technical. If the implemented solution had to be substandard to accomodate the time constraint then you should be clear about what compromises were made, otherwise they'll have no idea what they are agreeing to, nor will there be an expectation that they should understand that "kung fu" means that there are latent deficiencies in the codebase which may cause future complications.
    – J...
    Commented Nov 1, 2016 at 17:21

This type of situation is not as uncommon as you would think. It sure can feel like impending doom.

It is highly likely they are trying to salvage something from their investment in something for the least possible extra investment. This is why the have only assigned one junior developer to it.

Until software solves a problem for somebody in such a way that they are willing to pay for it, the software is worthless. If it needs features to get it to this stage then that is the best place to invest in the software. Spending time fixing something that nobody will pay for is not good allocation of resources.

Imagine if you didn't do what you were asked and spent time fixing bugs, then at the demo a critical feature for the customer was not present. That could result in a lost sale and would be entirely your fault. You don't know the reasons for all of these decisions so stick with them.

I know ideally things should be well written from the start, but you didn't start the project so can't be held responsible for the whole system.

It is unlikely (though not impossible) that you are being set up to fail. It is more likely that the business is trying to make something out of what is currently a dead loss.

So do what you can to help the demo go well. You have been clear from the start about the state of the code and have taken priorities from the management. If the demo doesn't go well it is not because you were not doing your job well.

If your company has a reasonable culture then this should be fine.

If the company has a blame culture and you get blamed for the demo or the state of the code, despite all of your advise to management then you can be more defensive next time. Get everything in writing, be more stubborn about fixing bugs. If you get called up on this then point out that you have taken the heat in the past for not doing so. Working in such a culture is not nice and you do need to watch your back (if getting another job is an option then look for one)

But I would suggest giving your company a chance. Do what you have been asked as well as you can and accept that the company is a joint endeavor.

  • 25
    "Until software solves a problem for somebody in such a way that they are willing to pay for it, the software is worthless. " Thanks, needed to hear that and makes a lot of sense
    – Prodnegel
    Commented Nov 1, 2016 at 17:24
  • 2
    This is a very reasonable answer, +1. Do the best job you can, always. Make your company great again.
    – Rocky
    Commented Nov 1, 2016 at 18:34
  • 4
    Rewriting from scratch is usually a bad idea. joelonsoftware.com/articles/fog0000000348.html . That being said, each time an existing bug is preventing you from writing a new feature, it's time to make a local clean-up. Just local, to stay in focus.
    – gazzz0x2z
    Commented Nov 2, 2016 at 8:41
  • 2
    @JaredSmith It's old, but all those arguments are still perfectly valid. They're not exclusive to shrink-wrap either - rewriting is a huge cost, and it eliminates all your advantage. If you need to start your consulting-ware from scratch, where do you get the headstart on your competition?
    – Luaan
    Commented Nov 2, 2016 at 12:06
  • 3
    @Luaan we're talking about software, in the context of the OPs question, that no one is apparently using for anything. There's no design document, no spec, no suite of tests that indicate desired functionality. Its buggy in ways that are obvious to a junior dev. Trying to salvage it may well just be pure sunk-cost fallacy. Spolsky was talking about rewriting working software being used by lots of people. You are absolutely correct about the arguments he uses in that case. Commented Nov 2, 2016 at 13:55

This sort of code base exists surprisingly often, and many of us have worked on similar. (It has been remarked that a codebase is a reflection of the organization structure that produce it - or indeed, a moving chronicle of the organization). Here is a pragmatic approach I've learned:

  • The management don't know the code base (that's actually a strength as well as a weakness), totally don't care about bugs, and are only incentivized to add new features. So it's infinitely easier to sell them that you're working on the latter (revenue-producing), not the former (cost sink); it's easier for them to sell this both internally and to the customer.
  • So when the project starts, super-quickly do a triage of what the worst bugs are and either add failing test cases or harnesses, or at minimum document the scenarios in a bug-tracking system ("When I do X on Y, it fails with result/error Z"). Revisit this intermittently, as time allows, or as the apparent existence or severity of bugs with respect to the features under development changes sufficiently. It's a very hard discipline to quickly triage stuff that ought to be fixed but time doesn't allow. But write the bug reports and scope out the fixes with the attitude that some unknown day time and budget may magically arrive.
  • Then as you scope adding features, any related refactoring and bug fixes become a dependency of the feature, get included in the work, time estimates, test scenarios. How you define and report that work, is your call. Only you know how to get it past them. As long as the executive summary says "Implementing feature X", they won't care.
  • Approach demos by having internal rehearsals weeks before, as an opportunity to show them "We implemented the code for X but it has bugs A,B,C which must be fixed". Actually, schedule giving an internal demo to your management regardless whether customer is asking for one. Gradually get them used to factoring in x% of time for bug fixing and testing in your estimates, or conversely, doing the first demo weeks before you expect working code.
  • "Work in their world, not yours"
  • 3
    Good answer and I love last point. In comments OP said that they are just "small cog". But that's only true if you are not trying to influence project more, besides coding. Work with your management, give them ideas and new solutions how to approach challenges from your POV. They take decisions, but you have influence with offering solutions. First, ask them, as this answers suggests, for reahearsals. Try to negotiate time for it, at least week before client's demo. Then try to make it common practice for all demos, then you may follow @TheWanderingDevManager advice... Commented Nov 2, 2016 at 5:45
  • 2
    and try to make demos with client more frequent. And so on. You will hear many reasons not to implement your solution - that's fine. Good management have more info on available resource and sometimes it's just not possible to use great solutions in project workflow. But don't stop! Some solutions will be appropriate and will be implemented. And that's the way how professional influence project and company, without manager position. And that's the way how you can stop being small cog and become serious professional. Commented Nov 2, 2016 at 5:50
  • 1
    This is a brilliant answer! Instead of just hoping that the OP doesn't get blamed, you actually describe how to make sure that it doesn't happen. Commented Nov 4, 2016 at 11:40
  • 1
    @smci: I fully agree that this is not a panacea. It is just way better than doing nothing and hoping for the best. Commented Nov 4, 2016 at 11:55
  • 1
    This matches my experience: it's best to fix bugs, refactor out bad design, and make improvements as you go.  That way, you already understand that area of code as well as you're going to, you won't need much extra testing, you avoid the risks associated with major changes, and you don't need to justify what might be seen as unproductive work.  Know where you want to end up, and be constantly taking small steps in that direction.
    – gidds
    Commented Aug 28, 2021 at 15:26

Assigned an uncommented, undocumented, mess of a project with no training or mentors. I am the only person working on this project, nobody else knows or has ever seen the code at all.

Step 1: Anything you touch you firstly write unit tests for, both to verify that it already does what it should (or show it doesn't), and to show you haven't made it any worse. You factor this into any estimate. This also forms documentation for the code as people can understand it from the tests.

Now months have passed and it is soon time to show program

Step 2: ensure you have regular demos/previews with the client, both to set expectations and to ensure you are doing the right thing/priorities.

Since refactoring is and never was an option due to time constraints and manager's wishes

Step 3: when you have a discussion like this, document it in an email to confirm. That way you make sure the dirty stick points in the right direction when they start passing out blame.

since I had to do some weird things to bypass the bugs

Never hide bugs, raise them, add them to a bug tracker and get a judgement call on fixing it (see above)

How can I avoid being chastised for a project I inherited which was already buggy, while I was told to work on more features instead of bug fixing?

Do your due-diligence when you pick up the project, not when everyone is about to find out it's gone south.

  • 11
    "Never hide bugs, raise them, add them to a bug tracker and get a judgement call on fixing it (see above)." This is gold. If you reported a bug and were not directed to fix it (or directed not to fix it), then there will still be a bug. (If you get resistance on using a bug tracker, point out that there's no other way you can keep track of bugs. You don't want to forget them.) There should be lots of emails back and forth about how to prioritize bug fixes over features. Commented Nov 1, 2016 at 21:09
  • 4
    #5) It had already gone south since the beginning! I told my manager that I wanted to start with refactoring/bug-fixing but he told me not to. Not sure what else I could have done in my situation.
    – Prodnegel
    Commented Nov 1, 2016 at 21:30
  • 9
    Mostly this is good advice, however "Anything you touch you firstly write unit tests for": insisting on full TDD is generally not going to work with/ get support from bad mgmt. You have to triage the worst cases and deal with those, as priority - see my answer for fuller. It is frustrating.
    – smci
    Commented Nov 1, 2016 at 23:25
  • 7
    @Prodnegel "I told my manager that I wanted to start with refactoring/bug-fixing but he told me not to" - and if you are straight out of college and your manager is reasonably competent, that was exactly the right instruction. Otherwise, after 5 years work you would have a beautifully structured code base that doesn't meet any of the user's new requirements yet - and when you started to implement them, you would probably have to refactor everything all over again! Real world software development isn't like doing college projects!
    – alephzero
    Commented Nov 2, 2016 at 2:08
  • 4
    @Prodnegel "I don't think any new developer out of school would be allowed to plan demos" - the common feature of all good software demos is, "you only demonstrate the stuff that works". Everybody in the real world knows that software has bugs, but they don't want to waste their time being shown bugs that they don't even care about.
    – alephzero
    Commented Nov 2, 2016 at 2:13

Every developer thinks that every project they inherit is a buggy mess, it's a natural reaction, and I understand the instinct to want to refactor everything to be the way you think it should be.

However, if the code already there is working and serving its purpose, and the business needs new features added, then you should focus on adding the new features.

It doesn't mean you can't refactor as you go.

As you add the new features, you are probably going to work with the already existing code, and when you do, tidy it up and add tests, and make sure that the new code is covered by tests also.

Brownfield development (ie. working with and improving existing crappy codebases) is a skill in and of itself, and you can't just rewrite every codebase in this category you encounter.

You are much more valuable as a developer if, instead of just finding a new job, you actually make the effort to work with and improve the codebase you have.

  • 1
    "working and serving its purpose" - it sounds a lot like this problem project is not doing that.
    – Gusdor
    Commented Nov 3, 2016 at 21:13

At the risk of being flippant, the world is hungry for programmers. Some organisations are broken, if perhaps, that is the case, then look for a new job.

Other posters have quite rightly pointed out that the inherited mess is common, even inevitable when it comes to large, long running projects. It is up to the company to resource the effort to fix or improve it not you (unless you have an equity stake). If it is time for a rewrite, then it is on them to decide (you can only suggest).

Look out for yourself in this situation.

I've been programming for over 30 years and after awhile you really notice how important the surrounding infrastructure is to you doing your job well. And you have a right to try to do it well.

If it is not good move on, start looking while you are on the current job, if possible. Just be careful how you phrase that to prospective new employers, complaining about how bad it was in your last job wins you very few brownie points.


I'm afraid you're too late to really do much about the impending issue. You can't blame your predecessor now as (s)he's long gone - you could have (with an e-mail trail) during the first month or so but not now.

If this happens in the future what you do is:-

  • Quickly assess what you've inherited.
  • Inform your manager by e-mail and recommend suitable remedial action instead of bug fixing for a few weeks before you continue.
  • File away (Print out and keep in a file at work AND at home) any refusal/insistence on new features to cover yourself later.
  • Push back gently any request for new features saying you're frightened you may destabilise a fragile codebase. File away the final decision from your manager as above.
  • Write unit tests for everything you add.
  • Pad every estimate you give for a new feature beyond that of adding unit tests (How can anybody contradict your estimate, they don't know the code?).
    Then, using your "extra" time:
  • Add more unit tests for the buggiest areas (like other people suggested).
  • Fix the breaking tests.
  • Refactor the old code.

Your situation will then improve with every New Feature.


You're in a situation where you have 0 professional experience, and have been asked to do work on a buggy mess of a code base and told that you can't fix the bugs or refactor.

However- 1. You have no idea if the code base is good/bad/typical. You have no prior art to compare it to. 2. Nobody is reviewing the work you do, which means that it would be impossible for you to know if you are making the code base better even if you were refactoring... again, you have no experience. 3. Nobody else looks at the code base, so you could actually do as much bug-fixing and refactoring as you wanted since your manager couldn't tell the difference.

I understand everyone has different situations, but finding an environment with a couple people who know what they are doing and a healthy code review process will be worth more to your career than what you will earn in 10 years in this company. So- I wouldn't worry about the upcoming demo (which will go poorly through no fault of yours, rather, your manager is entirely at fault here) ... I would focus instead on getting yourself into a better situation, whether that means finding another job or finding a way to get support from more senior developers at your current one.

(Someone with some solid experience could adapt to these situations, as the other answers describe. However, right out of college your first priority has to be learning to do your job, which you are not doing right now.)


A lot has been said that I agree with, but I think there's one more thing that ought to be mentioned: this is a tremendous opportunity for you.

Think about it. You, a junior programmer fresh out of college and with absolutely no experience, are the only person assigned to work on a software application. That tells me that the software is very low on the priority scale of management. They've effectively written it off; in their minds, the software has already failed (and from what you've said, it's not hard to see why they've reached that conclusion).

That means you can't fail; you can only succeed.

My advice is to trust your management, add the features, and demo them in the way that Pete laid out in his answer. If your management is smart, they're trying to sell the client on the capabilities that the application provides, which is not the same thing as selling the application itself. I'm guessing that if the client bites, they'll negotiate a price that includes fixing up (or even re-writing) the buggy parts of the code. It that happens, you'll be front and center in that part of the effort. If it doesn't, your management has lost nothing except a few months labor of an extremely junior (i.e., inexpensive) programmer.

There are a couple implications to this way of thinking. The main one is that, in addition to what you're already doing, you should start thinking about how much time and effort it would take to fix up the code. Start thinking about a plan and timeline, so that you can provide some options to your management. If they don't have a buyer, they won't be interested. But if there are any potential buyers, that sort of information will be crucial to them when they start negotiating on price.


Hopefully, you have not just told him but let him know in writing about the mess. This way, he knows the situation from the beginning and can't hold you responsible.

It's been my experience that in this sort of situation, the manager is often as happy as the developer to blame the guy who's left the company!

It would probably be helpful for you to track every bug you discover and keep them somewhere your manager can easily see (not in a passive-aggressive way, mind you - just tell him what you're doing). Even if it's in a shared "known issues" spreadsheet somewhere if your company doesn't have bug-tracking software. Maybe encourage users to do the same (in the same document) if politics and logistics permit. You might even be able to get your manager to assess the severity and assign a priority to each one (with respect to the new features you've been asked to add)

I'm guessing you don't have a fully functional QA department or it wouldn't have gotten this far, but if you do, their input here would be really beneficial.

This not only shows you are proactively trying to clean up the mess but also covering yourself if an issue arises where he could potentially blame you.


Get your boss to back you. Make sure your boss is convinced that there are serious problems so he can get time and agreement from senior management. Then get the best architect in the company to help you redesign or refactor or rewrite the project. Work with your manager and the architect to create a demonstrably better program. This happened to me the past 6 months.

You must log in to answer this question.

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