> It seems to me that a lot of what prevents developers from> fixing things is political or otherwise non-technical.

Very true. A change was requested on my current project. It took me about 20 minutes to diagnose. 1 minute to add 1 line to an XML file. 10 minutes to test. Another couple of hours to get hold of the user show them the solution and get their acceptance. And (a mandatory) two weeks from raising the paperwork to making a change to a live system, so the the required signatures could be obtained.

(Of course, had it been written in Smalltalk rather than Java then some of those steps could perhaps have been reduced massively.) :)

At the moment I'm refactoring a legacy code base, partially written by myself. It works pretty well actually, the reason for refactoring is that the requirements changed and in order to serve the business use cases it needs to be refactored.

At the time of writing that code, it was actually very clever and as said before, it worked pretty well. Looking at it now, I just think it's just ugly and I have the feeling of refactoring all of it. That's not only the case for the code someone else wrote, but also for my own code.

I'm wondering: if you say something is ugly, it's kinda insulting, right? So if code worked pretty well and served it's business requirements, but it looks strange today, is it okay to call it ugly?

> I'm wondering: if you say something is ugly, it's kinda> insulting, right? So if code worked pretty well and served> it's business requirements, but it looks strange today, is> it okay to call it ugly?

Sure. Ugly things can function very well. In this case I think ugly is another way of saying 'hard to maintain'. Perhaps that is my own personal bias.

One of the things that I saw as a problem at my last job was that there was a lot of focus on objective metrics. Maintainability is something that is very hard to judge objectively especially before any actual maintenance is done. So in the context of measurable performance, maintenance concerns were ignored completely.

OK so I'm going off topic here a little but I think this is related to the McNamara fallacy:

"The first step is to measure what can easily be measured. This is OK as far as it goes. The second step is to disregard that which can't easily be measured or give it an arbitrary quantitative value. This is artificial and misleading. The third step is to presume that which can't be measured easily really isn't important. This is blindness. The fourth step is to say that what can't be easily measured really does not exist. This is suicide."

> At the moment I'm refactoring a legacy code base,> partially written by myself. It works pretty well> actually, the reason for refactoring is that the> requirements changed and in order to serve the business> use cases it needs to be refactored. > > At the time of writing that code, it was actually very> clever and as said before, it worked pretty well. Looking> at it now, I just think it's just ugly and I have the> feeling of refactoring all of it. That's not only the case> for the code someone else wrote, but also for my own code.> > You make a key point here.

I give myself and my colleagues the benefit of the doubt and assume we didn't set out to write ugly code. But what we once thought pretty can become ugly over time. In our inexperience we can write code we think is fine but others, and later ourselves, can find ugly. So that's part of what happens.

The other things that happen are that requirements do change, and technical debt grows.

As requirements change, we find that what worked fine before becomes an impediment to further work. We have to refactor and establish new abstractions that solve both the original problems and the new ones.

Just to throw in a metaphor: a fresh coat of paint looks pretty sad after a decade in the sun and rain.

> I think the term 'maintenance' means different things to> different people. 'Maintenance', in my mind, not only> includes fixing bugs but implementing new features into> existing code a.k.a 'enhancements'.

One thing that seems to be true: I rarely run into teams that characterize what they do as maintenance, but if you leapt back 10 years, that is what everyone would call it.

I think that part of this is because of agile and another part is because of creeping maturity. Greenfield doesn't happen as much, so maintenance is the new norm.