It happened to me in the past that for some reasons a project (software app) has become very messy, or we inherited it that way.

With messy I mean that some basic best practices was not followed at some point, and as a result everybody was a little scared to touch anything because you don't know how it's going to affect the whole (say at this point the project misses 10% to be completed), this leaded to a even worse situation. We realized this status too late, when the project was close to be finished and we hoped we needed very little maintenance.

But I'm wondering what to do if the situation comes again, of course you should avoid the project to get to a point where you're afraid to touch it, but once it's there, is it acceptable to make an exception, limit the work do do on it and fix each problem the short way. When does it worth to refactor it anyway, going out of budget?


  • 4
    Sorry, I'm not 100% sure what you're asking. My suggestion is to give a specific example of the problem you are facing. Also, I'm not sure what you mean by "snubbed". You can edit your question to add more details. Thank you.
    – jmort253
    Mar 7 '11 at 4:01
  • Yes sure, I'm sorry, but unfortunately I'll have the time only in a few hour.
    – ecoologic
    Mar 7 '11 at 9:10

The way you tackle this kind of situation depends on a set of conditions:

  • Will a project be actively developed in future?
  • What arrangements with client do you have regarding SLA and generally fixing bugs?
  • Is is an important project for both client and your company?
  • etc.

In short you should try to answer how painful it would be to for you/your team/your organization to live with the project without improving its quality. Sometimes it's the best idea just to accept how it looks like and move on.

On the other hand if leaving low quality is going to be royal pain in the neck it's better I'd try to pay at least some technical debt back. How far you can go depends on the organization and your role. I would generally discuss openly the issue with project sponsor and try to reach some agreement how much time and effort you can invest to turn project maintenance into more profitable venture.

The more you do the better project should be but it should be treated more like an investment than trying just to be as perfect as possible. As a rule of thumb - if investment in project quality improvement can be judged with expected savings I'd go for it. So should most of decision-makers.

Edit: The link has gone dark, wikipedia has a definition.

  • good answer, but I wouldn't dislike to read some more ideas. thanks
    – ecoologic
    Mar 8 '11 at 18:19

I'd like to suggest a couple of things that you could do.

  1. If your organisation maintains a 'lessons learned' file (which they should), analyse where the project went off the rails, and get these lessons into the corporate memory so that the mistakes don't recur. If there is no such documentation, be the one to create it! But that only helps for future projects.
  2. Regarding the current project: if it is likely that the system will be further developed, you need to think about how easy it will be for someone new to step in and do that development. If it is a real nightmare of spaghetti code and poorly designed features, it may be most appropriate to "come clean" with the project sponsor and ask for a follow-on project to put this one right. There should be a positive return on investment (ROI) in terms of avoiding future difficulties and hence delays and costs, as long as the people who made the mistakes can be relied upon to not make the same mistakes again. I don't think you should just take on the recovery without proper buy-in from the business.

A more radical solution would be to accept that this system is fundamentally flawed, and should only ever be touched to fix faults during its life, and immediately start on a new project using different developers and more rigorous quality checking. Or try to buy an off-the-shelf product that does most of what you need!


It sounds like a project is 'reported' as 90% done, but there are a lot of problems - or in other words, it's really not 90% done....a very typical condition. Couple of recommendations:

  • don't stop work on the project
  • have someone 'objectively' review and report on the state of the project, gap analysis, impact to delivery, list of top issues and cost/time to address
  • report to Sr. Management ASAP the concern and the results of the review and a recommended plan to address (never go in without a plan)
  • maintain focus on the key delivery areas (those areas/functionality that is required to go live and provide value)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.