3 ms·

> 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

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

acveilleux 12y ago
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.
- algorithmsRcool 12y ago
  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.
  - chris_wot 12y ago
    You aren't working on a certain application that deals with ITSM by any chance are you? With a "polling service"?
    - algorithmsRcool 12y ago
      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.

3 ms·

> 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

by algorithmsRcool 12y ago

acveilleux 12y ago
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.
- algorithmsRcool 12y ago
  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.
  - chris_wot 12y ago
    You aren't working on a certain application that deals with ITSM by any chance are you? With a "polling service"?
    - algorithmsRcool 12y ago
      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.