While I largely agree, any change to debugged working code has a cost.

This is allied to my other favourite...

"If you broke it, you fix it."

Tends to improve staff levels of responsibility (and accuracy).

Before anyone says, yes I know they may need help to fix 'it' but having to ask is part of the learning curve too.

I agree to a certain extent. Currently I am responsible for a large application I inherited. This application is completely undocumented, no requirements to be found anywhere, no test plans and the product owner changes his mind on how its "always" worked daily. In my 12 years its by far the worst code base I have ever had the displeasure of working on and there is no hope of rewriting it anytime soon.

Any change to this thing that is not explicitly approved by the product owner is frowned upon, and they like to control technical decisions.

Everytime I click build another angel dies.

I don't own it, I am chained to it, but this is probably an exception to the rule. I am not the captain of the ship, the product owner is, I am just a lowly deckhand.

So bizarre to see Howard and Costello... was not expecting that.

I must agree although I have been guilty of this many times before. Sometimes just getting to grips with the code you've inherited while keeping up with current assignments is tough.

It'll be well worth it in the end though when someone asks you whats going on and you can actually give them a straight answer

I'm pretty sure it was Howard's fault.

This is a common phenomenon and I think it is due in large part to human nature. But we're not humans, we're developers. ;) I whole heartedly agree about taking ownership of the system and making it livable but also am realistic about two things. Business priorities and scale. If fixing the codebase conflicts with higher business priorities sometimes you have to just suck it up and keep pushing for some refactoring time on the schedule. Other times the codebase is just to large to cleanup within a reasonable time, then you just have to treat the refactoring as a iterative process. I personally took ownership of a really nasty 10y/o old codebase almost a year ago and have been doing minimal impact refactoring on each piece of code I touch adding unit-tests as much as possible. Right now I'm in the midst of doing some cleanup on a really gnarly service because it was acting up anyway. Instead of sying it's to big or I don't have enough time, stop thinking of refactoring and cleaning up as a separate step but something you do continuously and eventually you'll get it under control ABR (always be refactoring)

In AR the fault is always of the one gone away, always. ;) ahahahahah.

One should receive praise for the improvements made. One should receive blame for problems inherited only if he/she is given plenty of time to clean it up. In other words, in evaluating how good of a job someone has done, change in state is key, not current state per se.

Time is rarely given to "clean up" working code. There are too many other projects that need to be worked on.

Unfortunately program manager is right on. The business does not want you to spend time on anything that is "already working" but rather have you add new features to the mess or work on different projects.

@Dmitry & program manager:

Most of the time, however, the amount of time spent on adding new features quickly spirals out of control with a rotten codebase. Refactoring/redesigning is very important to keep your code healthy, and open to extension.

Yes this is absolutely correct, when you have the ability to steer the ship when the problem person was there and did nothing. And now that he's gone you still chose to do nothing.

Responsible, yes. To blame, no. The reality in most organizations is that you don't get to fix code the way you'd like. Developers don't have free reign to just alter existing code. They answer to people who set priorities for them. The responsible part comes in when they get are asked to extend that code. Now it is the dev's responsibility to "Speak Truth to Power" and tell their managers or whomever why adding some simple functionality is going to take months rather than days, and then do the work the right way. That takes courage, and a responsible developer, living up to his/her charge as professional will do it.

So, you might want to cut a little slack to the "owners" of this code you are reviewing. Especially after only three months. There are code bases in my organization that royally SUCK. I am grieved every time their wretched titles are brought up. But as someone above said, they work, and the business often doesn not want to spend any more money doing what they WRONGLY percieve as making a perfectionist developer happy.

@Erik

We developers know that, but unfortunately management or clients do not always know that. They control the money and what tasks you are allocated to. We should try to convince them that messy code costs money in the long run, but it is not always they want to listen, and in some cases, the best decision from a business stand-point is not fix the code!

It hurts my professional pride when this happen, but that is the life in the corporate world.

BTW: One week is not a lot of time to fix code in most products.

The article and comments are the typical issues (pro and con) surrounding "technical debt"

http://en.wikipedia.org/wiki/Technical_debt

"And no, saying that X did that this way is not a valid option if it past a week from the time you got the code base. "

Our code base is something like 3 million lines of code in about 200 separate projects. I think we'd need a bit more than a week to undo all the damage of the previous regime...at least give me 10 days. :)

A bit tongue and cheek there, but sometimes due to the shear size of a code base, you are stuck with it.

Hi Ayenda,

I totally agree with your last words.

If something bad happens, no matter who has caused the error, since you are maintaining or you are making developments on that code, you will be the responsible person for the fault.

But for the code review part, there is a very well known saying: If it is working, do not touch.

While trying to make things better, we should take precautions against new bugs.

ASP.NET Programmer, I am guessing you haven't tried TDD. Once you do, you will see that the ONLY time you should "touch" (meaning refactor) is when it is working.

G'day Ayende,

Love the use of the old Australian Prime Minister for the cartoon.

Great post, geat work with Nh, linq to NH etc

Keep up the awesome work,

From another satisfied user of NH.

Hurray for the notion of taking responsibility!

However, I don't agree that having code handed to you means that you should instantly go clean it up. I think these huge "refactors in the sky" tend to give the notion of refactoring a bad name.

I prefer to clean the code AS it effects me. That doesn't mean only when I need to modify the code. It could simply mean that I have a need to UNDERSTAND what the hell that code is doing in order for me to do whatever I need to do. And, a lot of times with code that gives me migraines, the fastest/easiest/most painlss way to understanding it is refactoring it into something meaningful.

But, until I have a reason to understand it, I don't see a compelling reason to touch it. What do you think?

I'm in a similar boat to @Scapegoat, above. There's one particular project where I would LOVE to clean up the code, I'm just not allowed the time or freedom by the respective management folks to do so. The best I can do is clean up in the areas I have to touch when features are added or defects are fixed.