I would like to ask you some questions about dirty code. There are some beginners who coded on a medium project. The code is a very huge ball of mud. They are not advanced programmers. They just know how to use keyboard an a little about java. They just wrote code with 12 000 lines in their main class, though, 6 000 lines belongs to NetBeans itself.

My job is to analyze the code and suggest a good way to maintain the code. My idea is to scrap the project and start a new one with OOP methodology. Recently I collected some notes and ideas about the problem, from this site and some others.

Now, I have the followings questions:

  1. Should we repair the code, and change it to a OOP? We are now debugging it.
  2. The code has no comments, no documentation, no particular style of programming, and so forth. Changing it is really expensive and time consuming. What do we can do about this?
  3. How can I teach them to follow all the rules (commenting, OOP, good code quality, etc.)?
  4. The code is erroneous and error prone. What can we do? Testing? We almost write two or three A4 papers for correction, but it seems endless.

I should have to say that I am new with them. I think I have broken the rules about adding people too late to the project, as well. Do you think I have to leave them?

  • This needs to be split into two or three questions, it's far too broad at the moment. Dec 4, 2010 at 9:24
  • 2
    Is this project under version control? Dec 4, 2010 at 18:04
  • 2
    Is the current code in production?
    – JeffO
    Dec 4, 2010 at 19:08
  • Yes Jeff. It is a production, a management project for administrating a financial issues!
    – Salivan
    Dec 8, 2010 at 7:18
  • Sorry JBR, they did not hear of a thing like that. Just making a coupe of copy paste codes all over the hard disk is their techniques to perform version controlling.
    – Salivan
    Dec 8, 2010 at 7:20

8 Answers 8


Step 0: Backup to SCM

Because, as hinted to by JBRWilkinson in the comments, version control is your first line of defense against (irreversible) disaster.

Do also backup software configuration details, procedures to create deliverables, etc...

Step 1: Test First

Then start by writing tests:

  • for what works,
  • and for what fails.

No matter what you decide to do, you're covered. You can now either:

  • start from scratch and re-write,
  • or fix it.

My advice would be to start the general architecture from scratch, but extract from the mess the parts that validate checkpoints and to refactor these as you see fit.

Step 2: Verify and Monitor

Set up a Continuous Integration system (to complement step 0 and step 1) AND a Continuous Inspection system (to prepare for step 4).

Step 3: Stand on the Shoulders of Giants

(as you always should...)

Step 4: Clean

That sort of goes without saying, but instead of skimming though the code yourself, you may want to simply run linters / static analyzers and other tools on the broken codebase to find errors in the design and in the implementation.

Then you might also want to run a code formatter, that will already help a bit with the housekeeping.

Step 5: Review

It's easy to introduce tiny bugs by refactoring or cleaning things up. It only takes a wrong selection and quick hit on a key, and you might delete something fairly important without realizing at first. And sometimes the effect will appear only months later. Of course, the above steps help you to avoid this (especially by implementing a strong test harness), but you never know what can and will slip through. So make sure to have your refactorings reviewed by at least one other dedicated pair of eye-balls (and preferably more than that).

Step 6: Future-Proof your Development Process

Take all of the above, and make it an inherent part of your usual development process, if it already isn't. Don't let this happen again on your watch, and work together with your team to implement safeguards in your process and enforce this (if that's even possible) in your policies. Make producing Clean Code a priority.

But really, test. A lot.

  • A great suggestion - doesn't matter what damage you do if you have tests that can catch the problems. Of course, we're all assuming that they have version control already.. Dec 4, 2010 at 18:04
  • @JBRWilkinson: good point actually! Indeed, completely assumed they did.
    – haylem
    Dec 4, 2010 at 18:08
  • 2
    Start version control first; better late than never.
    – JeffO
    Dec 4, 2010 at 19:00
  • @Jeff O: yes, it's already what I added to the answer.
    – haylem
    Dec 4, 2010 at 19:14
  • Rewrote to make clearer after edits. Left attributions :)
    – haylem
    Dec 4, 2010 at 19:32

Personally, I wouldn't start this project until I have a copy of Working Effectively with Legacy Code handy. Seriously, it was written for exactly this type of thing. It's full of strategies for dealing with tricky code, and goes into far more detail than I can give you here.

  • 1
    +1 for use of extensive external reference that says it all.
    – haylem
    Dec 4, 2010 at 17:26
  • Unfortunately, here people have no idea about reading books. Just developing a project that it works is all they need. I started to read you-mentioned book, and CODE COMPLETE 2, too. Let me say they are wonderfully written.
    – Salivan
    Dec 8, 2010 at 7:38
  • 1
    @Salivan - Perhaps they just haven't had anyone convince them that such books are worth reading. If only there were a person that worked with them who was interested in reading such books... Dec 11, 2010 at 8:59
  • 1
    @Salivan - the key thing is to find a quick win or two. Do something that has an almost immediate payback. Like version control, so the next time someone says "how did that happen" you can look it up. Then lead them into some suggestions from your reading of your copy of WELC. Don't just throw the book at them.
    – Мסž
    Jun 1, 2011 at 0:24
  • 2
    @Salivan You can read the books for them, and drip feed the content to them as advice. You might become the team guru.
    – MarkJ
    Jun 2, 2011 at 12:07

I have been there several times. My rule is: if the software is not trivial (more than 1 week work for the resource you have) and it does work, then keep it and proceed with incremental refactoring.

If the software doesn't really work (very high number of bugs, unclear requirements etc.) than it's better to rewrite it from scratch. The same if it's quite small.

The point in refactoring (as in the Fowler's book and Kerievsky's one http://www.industriallogic.com/xp/refactoring/) is that it keep the system working, maybe the refactoring will take double time but the risks are zero.

Rewriting from scratch could introduce many risks, from misunderstanding requirements to wrong implementation (after all most of the team will be the same).

I actually saw a complex procedure being rewritten from scratch twice and still not working as expected.

  • I would also suggest writing unit tests for appropriate methods, if possible. They will help clearly define what the code is supposed to do in the first place, which will will aid the refactoring process.
    – Michael K
    Dec 5, 2010 at 0:06
  • 2
    It goes without saying... I consider TDD a requisite for any good code (aka the new one).
    – Uberto
    Dec 5, 2010 at 10:19
  • Writing from the very start is a very good idea. But first you need to have some diagrams of the work. But what will you do if you have to analyze the code to extract the relations? Besides, the size of the project makes it impossible, or it will make us to hire some other programmers.
    – Salivan
    Dec 8, 2010 at 7:43
  • Test Driven Development is appreciated!
    – Salivan
    Dec 8, 2010 at 7:44
  • "But what will you do if you have to analyze the code to extract the relations?" -> if this is the case it means the project is neither tiny nor broken. Aka I'll start doing refactoring one piece at time. See also the Mikado method. danielbrolund.wordpress.com/2009/03/28/…
    – Uberto
    Dec 8, 2010 at 9:18

I would re-write it completely. Sometimes it is impossible to repair such a code. Another option is to make it working, without adding any new features. To teach the team to write good code (well designed, documented, with tests) let them to fix the code you have now. Let everybody to fix bugs/review the code of other developers, not her/his part. After some attempts they will understand that it is almost impossible to review/fix such codes.

Adding people to late projects helps very rarely. Usually it breaks deadlines. You should do everything you can to finish the project successfully, and then think about leaving.

  • How much would it cost to re-write it completely versus iteratively improving it? Which approach would give results quickest? Dec 4, 2010 at 18:03
  • @JBRWilkinson It depends. The iterative approach is good, when you have working code.
    – duros
    Dec 4, 2010 at 18:09
  • 1
    @duros, for broken code, yes. This code runs in production.
    – user1249
    Aug 19, 2011 at 20:19

My advice will be not to scrap the entire code entirely. This is the day-to-day life issue, every development team face. Attack one part of the code at a time. Fix it, clean it, document it. And then move to the other part. The main thing is always keep some shipable code at the hand. Rewriting the entire code from the scratch will take the amount of the time that has been spent till now and there won't be any guarantee that it will be nicer than the current.
But then also the people should avoid writing the code in this manner. Spend some more time in code reviews. Adapt to some uniform coding style. Discuss the design first and then write the code. Such simple things will make big changes.

Nice Blog telling why Netscape loose

  • 2
    Starting a new project, while updating/debugging the old version in the mean time (and you cannot avoid this so don't dream about it) is trying to shoot at multiple moving targets.
    – JeffO
    Dec 4, 2010 at 19:03
  • "Attack one part of the code at a time" did not work, Manjo. with a deep sorrow, the code contains lots of errors. It always turns to something else. We should attack and destroy one part of the code and construct it then. I suggested this thought to the manager once, but the coders need to be off of writing any new codes.
    – Salivan
    Dec 8, 2010 at 7:48
  • @Salivan ... need to be off of writing any new codes . I'm sure management is saying this. But the first thing to do when you are in a hole is to stop digging (don't continue to make the same mistakes). To allow more to be created under these conditions is to continue digging the hole. The difficult part is how to get management and the coders to understand the issues.
    – SeraM
    Dec 19, 2016 at 17:44

If it works, refactor it. There are tools to help you do that. If it doesn't work, use the magical code improvement command, i.e. deltree on Windows resp. rm -rf on Linux.

  • 2
    Suggesting to "completely erase all the code" is particularly unhelpful - do you have a more constructive answer? Dec 4, 2010 at 18:01
  • LOL. I am completely agree with you, ammoQ!
    – Salivan
    Dec 8, 2010 at 7:50
  • JBRWilkinson: Doing a fresh restart is most likely a better approach than trying to make the mess work and clean. A company I've worked for tried that, and year after year, they had wasted lots of resources and got absolutely nowhere.
    – user281377
    Dec 8, 2010 at 9:20
  • @ammoQ, you need the old code to see what it actually did, when you get it wrong.
    – user1249
    Aug 19, 2011 at 20:20
  • 1
    Thorbjorn: We are talking about code that doesn't work, right? Analyzing uncommented, dirty code that doesn't do the right thing tells me more about the mental condition of its creators than anything else.
    – user281377
    Aug 22, 2011 at 7:44

Should we repair the code, and change it to a OOP? We are now debugging it. [... contains errors, no documention ...]

I've been there, you have my sympathies. I even wrote an article about this which might help you get some perspective. But in short:

If the code contains lots of duplication, you should rewrite. If there is no discernible structure (no clear interfaces, spaghetti), refactoring will fail and you should probably rewrite.

How can I teach them to follow all the rules?

Begin with explaining why they might want to do that by showing them what they can gain from it personally. When they agree with this and are willing to learn, start teaching them using shuhari.

  • Thanks Martin. "Begin with explaining why they might want to do that by showing them what they can gain from it personally. When they agree with this and are willing to learn, start teaching them using shuhari."
    – Salivan
    Dec 8, 2010 at 7:52

My suggestion is a combination of @duros's & @Manoj R's answers.

Start from scratch, keeping in mind to create good code/OOP/commented/etc this time, refer/copy&paste from your old code. As you meet the bad parts of your old code, rewrite/refactor them.

If your developers are not well trained, I think its good to send them for courses. Its important for regular retraining in the fast changing IT industry

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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