How can I avoid being chastised for a project I inherited which was already buggy, but I was told to add features instead of fixing it?

Question

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.

---

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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"

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.)

Answer 10

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.

Answer 11

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.

Answer 12

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.