When I read responses, I have the feeling many people underestimate how bad and unmaintainable a codebase can be.

Just to illustrate this, I’m working at place where the whole Project originated from one “main” file of hundreds of thousands of LOC. …the worst part is that the beast got bigger and bigger over time:

• methods having tens of thousands of LOC
• more than 15 levels of indentation
• GOTOs spread over them, breaking the loops
• pointer arithmetic, void* casted everywhere
• lots of “two letter” variable names
• lots of code nobody has an idea what it does
• nobody actually knows how the whole thing even works …but it works and make millions
• duplicated code everywhere with a couple of lines changed here and there
• obscure WINAPI stuff
• non-deterministic behavior because of uninitialized variables, buffer overflows, wrong pointers…
• no doc, no spec

Before I started working, I didn’t imagine something so catastrophic could exist. The costs for maintenance are of course astounding and everything is done to attempt to minimize the changes.

On the side, because everybody knows this is a nightmare, a new software “2.0” is made, but it’s so big it represents at least a dozen of man years.

I think, what you should simply talk about it to your manager. Talking makes wonders. What is important for them is to understand what the actual state is. That maintenance is really extremely difficult, time consuming, error prone, all of it because of the bad code. Moreover, continuing working on it usually even increases its technical debt because we add piles of crap based on other piles of crap. …but in the meantime, since it is productive crap which earns the company’s money, we have to deal with it, even if it’s hard and unproductive.

The other funny thing is that any idiot can turn a normal source code into a pile of crap. However, the crappier the code, the smarter the one dealing with it has to be. The bad side of it is that the idiot looked productive since he added features, and the brilliant one unproductive since he has to deal with its predecessor’s mess. Only good managers with technical expertise can understand what’s going on though.

Very rarely there is a case where there is an unworkable requirement, usually it’s a “I don’t want to”, being phrased “I can’t”.

Never use absolutes like “Can’t” and “Unworkable” unless you can prove it and are absolutely certain you have exhausted all options. You look like an idiot or a lair when it does get done. A number of times I have been told “That can’t be done ….” and seen it working a few days or weeks later, leaving the developers looking bad. It puts them and the rest of the team in a really difficult position next time, as they say “Can’t” and are not believed.

If you really can’t, provide alternates for consideration, with the benefits and drawbacks of each. Follow this with open and honest discussion. Focus on finding a solution, not defining the problem.

Your manager did not hire you to create problems. He hired you to create solutions. Never take a problem to you manager that you have not got (or at least tried to get) a solution for.

Well, I think that basically everything actually can be done, it’s just a matter of how much time it takes. On a bad codebase everything naturally takes a lot of time. So when you are saying something is unworkable, I take it you mean that it would take way too much time to implement a certain feature for it to be practically viable. I know a manager might think it’s just a small issue, you know, “we already have other features like this, how can it be so hard?”.

If your manager is the kind of person who does not understand when you explain them about the anti-patterns and the smells in the code, they should at least understand time and money. So create a good, solid plan on how you would implement the requested feature if you indeed are to do that. Take your time to analyze the code and split the project into manageable sub-tasks of no more than about 8 hours long. Draw a Gantt chart of the project stages. When you cannot provide an accurate time estimate, give at least some range: 10-30 hours is better than nothing. Explain the optimal case when it’d take 10 hours, and let your manager know of the conditions of the worst-case scenario of 30 hours. Then perhaps say something like “Given the general code quality, I’m pretty sure we’ll end up closer to 30 than 10 hours. Also notice that this task is on the critical path of the Gantt chart, so when this one is delayed, the whole project is delayed.”

You’ll end up with your project A taking, say, 100 hours. Then devise another plan, writing the requested feature from scratch. This might be difficult to include in your existing project if/when your interfaces are bad too, so remember to include the time of integrating the two systems together. This way you might end up with a project B that takes, say, 90 hours instead. That’s probably too close to the original plan for the manager to buy it, but then you should explain them how the new codebase would be way easier to modify further: if you implemented Feature 2 on top of Project A, it’d take 30 hours, but if you did the same to Project B, it’d only take 5 hours. At this point I’m pretty sure your manager starts seeing the things in perspective.

Professional pride (the bad kind, not the good kind) often makes coders feel like they have to plod through. In practice, I find it better to get together with the project manager (doing tougher discussions like this during lunch often takes the pressure off, IMHO) and discuss your concerns. Let them know the problems, perhaps insurmountable, you have found. Propose some sort of compromise, if at all humanly possible. For example, “We cannot add Foobar feature in the time allotted, but implementing FizzBuzz will take a quarter of the time and give us 75% of the functionality.”

Any project manager worth his salt wants to know these things and will be open to discuss concerns especially if you have some sort of solution.

Whenever someone assigns a task for you in that project, make an honest and careful estimation about the effort. If the thing is really “unworkable”, as you say, those estimations fewer or later will be adding up to a sum so high that your project manager will consider to stop the project.

(Or he will assign the task to someone else who does not think the same way you do about the thing).

You want to start by doing some sort of a cost-benefit analysis. You aren’t truly going to understand how important it is to simply start over without being able to prove that this is the best approach to take. This is not to say that your gut instinct is necessarily wrong, however you really need to determine for yourself whether it is a case of reluctance or professional pride holding you back from working on an existing product.

As bad as an existing code base may seem, you need to remember that there is likely already a sizable investment in it that your employer won’t want you to throw away without really good cause. The reality is that even if you have a very good reason for wanting to throw out the existing product, you are going to need to justify your reasoning, and to make this work for both your team and the company, you are going to need to be able to show not only how much the product is costing and could save if done another way, you are also going to need to show that there is a pathway to your “golden ideal” that won’t be prohibitively expensive, and you can be sure that this extra pathway cost is going to be counted against any potential savings you might think you can show for your rewrite.

What I am saying is that this is going to be a lot of work. You need to show what the product is costing to maintain as is, what it would cost to improve it to make it of a better standard, what it would cast to maintain while preparing to move over to a new product, what it will cost to develop a new product, and what the new product is likely to cost to maintain.

The reality though is that no product is actually TOO difficult to maintain. All products may be improved with a careful approach to refactoring and gradual improvement over time. This is also going to be a lot of work, but less likely to be as costly or effort intensive than attempting to justify throwing in the towel simply because the present code base is hard to maintain. When I hear someone say that code is unmaintainable, what I hear is that it is likely the code is unsupported by unit tests, likely unsupported by test/build automation, likely a lot of code duplication, and likely to be a lot of classes and methods that are all trying to do too much. These are all problems which are fixable to a very large degree if a little effort is applied to address them.

In a few very rare cases, you may have code that has dependencies over which you have no control. I’m talking old legacy 3rd party products that are being used by your code base, but which have been forgotten about because they were added years ago, and all of the experts have left without documenting why these products were in use. In such cases you might be justified in starting something new, however depending on the size of your product it is rare that this would justify rewriting an entire product from scratch.

I don’t think you can really find a definitive answer to your question. Much of this sort of thing really comes down to you, your team, company culture, time, available funding, and a whole mess of other things. This is the sort of stuff that you really need to sit down with your manager to discuss, and to work out as a team to determine the best path forward.

There’s really never a project that is completely unworkable if it can be designed or envisioned – the unworkable part may come from the choices that are made to implement the product.

For example, it’s perfectly okay to say that it is unworkable to develop an iPad application with only a Windows machine and a copy of Visual Studio. Other than situations like that, it’s better to think about things in terms of cost and opportunity.

Think about the solutions to the potential problem, and be open with your product manager about what is difficult, why, how you might solve it, and how you might need help in solving it. (Sometimes it can be a matter of not knowing a particular technology well enough to know what it’s really good at and what it isn’t good at.)

There is really no way to answer this without specifics. How important is this project for the company? How much time and money has already been spent? Are you proposing to abandon the project completely, or is it possible to reduce its scope, increase the time frame, or add more people?

If this is the main product of the company, and abandoning it means that the company goes belly up, then all you can do is resign. On the other hand, if you can suggest something constructive, such as dropping some features or allocating more time and people, then it is perfectly reasonable to take it up with the manager.

As Michael just suggested, the crucial point is: why this project is unworkable?

A project manager just wants to know this. Give me at least one really convincing reason to give up and I will do. I will try to limit the damage at its very least and I will stop the development.

As you can imagine, it is very, very hard to convince a project manager that a running project has to be stopped because of technical considerations. Even a total mess of code can be improved or rewritten.

Different is the case of business considerations. A project can lose its reason to exist during development. Maybe a new competitor has already occupied the intended niche, maybe the investor hasn’t any more money. There can be business reasons to stop a project.

My very personal suggestion is to identify with your best care the issues with the project, explain to your project manager why they make the project unworkable and what you can do to fix them.

Be constructive. Bring to the table every solution you can find. Do your best to save the project even if you think it should be killed.

The last decision must be left to the investor and to the project manager. If your explanation is convincing, they will stop the project.

This kind of problem is usually a disagreement over the time and resources required, and there are many ways to either negotiate for more time, more resources, a different development path, or different objectives.

If you can’t negotiate a satisfactory work plan, then your fallback position can always be “this project can’t be done by me (with these resources)”. If that doesn’t either cancel the project or move it to someone else’s plate, then it’s hard for management to hold you responsible for failure.

In any case, the important thing is that you do not accept a task you can’t complete just to placate your manager.