Comment by algorithmsRcool | Hacker News Reader

Comment by algorithmsRcool | Hacker News Reader

Parent Full thread

algorithmsRcool

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.

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! :|

> 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.

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/

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.

Reply on news.ycombinator.com