Comment by vinceguidry | Hacker News Reader

Comment by vinceguidry | Hacker News Reader

I think this is ultimately caused by developers not quite knowing where and how to place their ambition. It's easy to look at the big legacy app and be like, "I can fix that!" Then they roll up their shoulders and go to work, management be damned. Management can't see or understand what he does, and they're paying him for his expertise, so they give him the benefit of the doubt and let him do what he thinks he needs to do.

I documented my own answer to this situation here. Basically, don't treat organizational problems as technical ones. They're paying you to do a job, everything else you do is basically an ambition. First rule of ambition is to do no harm.

https://news.ycombinator.com/item?id=8768524

If you're going to refactor, don't refactor in the direction of new. Refactor in the direction of coherency. Do things that you can finish, or, that at least, don't matter that much if you don't. Like adding tests. Nothing wrong with that.

If you want to fix the legacy app, you need to make less ambitious changes, because you need to be able to finish them. Instead of changing the data types, refactor the initialization code. The initialization code runs once, data manipulation code is basically convention and you need to change it everywhere at once or not at all. Refactor it to the point where you can change it everywhere at once and then do that. Or get really good with a text editor and macro the changes.

Giles Bowkett has a great book on it. Unfuck A Monorail For Great Justice. It's Rails-specific but the ideas can work everywhere. Write code that understands code.

http://gilesbowkett.blogspot.com/2013/03/new-ebook-unfuck-mo...

But understand that there are probably better things to do with your time. You can pick out pieces of the legacy app and try to understand them well enough to rubber-duck debug them without having the source code in front of you. Once you have that then really, you don't need to be a hero. You're already a hero because you know the system better than anyone. You can focus on other things. Maybe use your new-found credibility to build some consensus among your peers and managers. Then when you make your case to replace the app, it won't just be you.

I feel like this is very sound advice but i'm not sure if i can really accept it fully.

I'm a fairly green developer (3 years professionally) working on an C# application that suffers from design schizophrenia as detailed in the article. I'm more or less the sole developer assigned to it now.

Although I am new, I feel very strongly about my 'pride as an engineer' in my application of sound design, knowledge and rigor to the best of my abilities. So it discourages me greatly when i hear a lot of "Uhh, that was a long time ago...", "We had tough deadlines..", "Well developer 'X' and me disagreed about that..." from the former maintainers of the code.

I've taken to a rash practice of just tearing out tightly coupled, untestable, duplicated and poorly designed code by the roots. I feel like i am somehow passing a 'holier-than-thou' judgment on the work of my predecessors. But due to it's tight coupling i can't have much confidence about even seemingly simple changes since they always seem to come back with a wagon of defects. The new code i write surely isn't perfect and has it's own defects that come back to me, but i feel much better about the code in many ways and i am always open to criticism and discussion over my design choices. If anyone would ever give them serious study...

I have this gut feeling that if i leave the code i touch messy that i'm not doing my job and the next poor soul to come behind me will lose weekends to trying to clean up an even deeper mess. I feel judgmental even voicing these thoughts.

> I've taken to a rash practice of just tearing out tightly coupled, untestable, duplicated and poorly designed code by the roots.

That's not a terrible approach. Depending on the context the code is running in, that might be a worthwhile way to maintain it, especially if there's not all that much different between doing that and working on it as is. If it's taking you the same amount of time, why not leave it better than you found it? The important thing is that you finish the job, and it sounds like you're doing that. You're not making a three-year plan, not telling anyone about it, and doing a little bit every day. That way lies the lava layer.

Me personally, I have like four other projects I could be working on. Give me a choice between working on old legacy and working on new hotness, I'll band-aid the legacy every time and just get on with life. I didn't use to do it this way. I wanted to make my mark on the legacy codebase, prove that I was better than it. So I'd tell my boss I'd need the rest of the week to implement this and then dive in. I'm happy I don't need to do that anymore.

> I wanted to make my mark on the legacy codebase, prove that I was better than it. So I'd tell my boss I'd need the rest of the week to implement this and then dive in.

I think this statement sums up my attitude almost perfectly. I have a notion that if I channel that line of thinking into positive structural changes in the code then I should while I can. I just don't know whether or not it is a good attitude to have.

My own experience is that it's easy for that to become either a source of a lot of regressions or an infinite death march. It's key to thoroughly understand the part to replace before getting involved in that kind of wholesale replacements.

The amount of tests available on the previous implementation can go a long way towards lighting the way and bounding the level of required efforts. Code that is deeply embedded, untested and "ugly" is just a recipe for pain however.

I need to work harder at mapping out our code to understand it as you say. I keep telling myself every codebase is different and none are perfect, but it is so nice to work in fresh or at least clean code.

My project is about 200KLOC C# 2.0; we have a single .cs file 13,000+ lines long and no, it's not generated. We have a single method 900+ lines long in our DAL containing 23 separate hand coded SQL queries and no, it is not a report. Our codebase contains exactly 14 unit tests. 10 of which were written by me. Your prayers are welcome.

You aren't working on a certain application that deals with ITSM by any chance are you? With a "polling service"?

Haha, nope. B2B software in the hospitality industry. It's both comforting and sad that my codebase's ugly stats might be shared by other applications out there.

What you're talking about is a bad implementation of a design stemming from its inherited technology. Essentially, attempting to refactor the technology or the design first is a bad idea - fix the implementation.

There's a book you really ought to read then. It's called "Brownfields Development" and it's sadly out of print. However, there are some free PDFs that might help you here:

http://www.manning.com/baley/

> I've taken to a rash practice of just tearing out tightly coupled, untestable, duplicated and poorly designed code by the roots.

Hello me, from a parallel universe!

You've basically described the project I'm currently assigned to and the situation I'm in as well, and I share your enthusiasm for "weeding" out obvious turds and warts from the codebase.

Unfortunately I've reached a new kind of roadblock when it comes to improving and refactoring the project: I've picked all the low-hanging fruit, and now if I tug at any of the remaining lose ends the whole thing will unravel.

Basically the remaining pain points are architectural ones (that will hurt us at scale) and that require attention but at the same time are large enough that management won't approve the necessary resources to work on them.

Honestly I almost feel as if I've fucked myself over by making those improvements: the project is now mediocre as a whole, but just good enough so that nobody really cares about improvements any more. Had I just let the ship sink, maybe something better would have come out of this whole mess in the end.

Not sure what the lesson here really is! :|

> If you're going to refactor, don't refactor in the direction of new. Refactor in the direction of coherency.

1000x times this. And making things coherent will make it a lot easier to put the new hotness in too. Add in the new hotness only when you can do it in a coherent way. If you can't do it in a coherent way, you might need to refactor until you can get there.

You might never get there in a legacy codebase, but if everyone took this attitude from the start, you might be less likely to end up there.

You can put new things in and change architecture, but you always have to do so coherently -- which does mean you can put in fewer new things, and sometimes not the new things you want to put in as soon as you want to put them in.

And oh, yes, so very much: "don't treat organizational problems as technical ones." Without understanding the organizational disfunction at the root of your technical issues (it's almost always there), you're doomed. Of course, then you've got to figure out what to do about the organizational problems (or how to operate succesfully in their shadow), which is not what you find the most fun part of your job, but that's how it is.

> Refactor it to the point where you can change it everywhere at once and then do that.

This can be generalized: refactor the code to the point where what you need to next is easy to do.

Reply on news.ycombinator.com