5 ms·

More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. A rewrite will so

More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. A rewrite will solve it in the short term - until requirements change again. However, I would much rather apply the new 'hacks' onto the rewritten 10 line function than figure out the original 200 line behemoth.

swsieber 8y ago
Each hack individually, yes, is likely to be there because of requirements changing. But collectively, it's likely that one of those hacks is there to account for some edge case that's not intuitive and will be missed on the rewrite.
organsnyder 8y ago
In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.
- eastbayjake 8y ago
  This is why we have the strangler pattern, right? You wrap the legacy functionality with a set of tests that define the functional requirements of the code, then your new refactored solution needs to keep those tests passing. (And then once you've done that, make sure that your "hacks and bugfixes" get test cases so you can make sure the next refactor accounts for them!)
- vorpalhex 8y ago
  Which is why comprehensive testing is important. If we have test cases that accurately capture our requirements, then we can refactor and know when we've err'd from the path. If we don't have test cases, then we have to make best guesses (and we know how that one turns out).
  - finaliteration 8y ago
    Accuracy is key, here. I came into my current job with some pretty awful tests in place that “passed” and showed good coverage but did absolutely nothing for actually hitting the necessary cases...
test6554 8y ago
I have some code I inherited that I have rewritten it twice now and the second time is when it really became stable and also easier to work with.
walshemj 8y ago
Or you rewrite it to be more flexible and seriously think about what if's eg what if sales tax was changed in the middle of a month/billing period. This is a real example at one job in the UK on budget day I used to listen the budget speech live in case it had any impact on the system I worked on.
- ruok0101 8y ago
  I worked with one guy once where he wanted the "ultimate flexibility" and every data model object basically became a database table with the columns 'key' and 'value'. Trying to think of everything ahead of time has its own problems...
  - walshemj 8y ago
    Which is how map/reduce systems work at the core - and how we implemented it back in the 1980's. Each record type and field in that record had its own entry in a MIDAS table so you could process say TELEX records differently to Email, Data etc.

swsieber 8y ago

Each hack individually, yes, is likely to be there because of requirements changing. But collectively, it's likely that one of those hacks is there to account for some edge case that's not intuitive and will be missed on the rewrite.

organsnyder 8y ago

In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.

eastbayjake 8y ago
This is why we have the strangler pattern, right? You wrap the legacy functionality with a set of tests that define the functional requirements of the code, then your new refactored solution needs to keep those tests passing. (And then once you've done that, make sure that your "hacks and bugfixes" get test cases so you can make sure the next refactor accounts for them!)
vorpalhex 8y ago
Which is why comprehensive testing is important. If we have test cases that accurately capture our requirements, then we can refactor and know when we've err'd from the path. If we don't have test cases, then we have to make best guesses (and we know how that one turns out).
- finaliteration 8y ago
  Accuracy is key, here. I came into my current job with some pretty awful tests in place that “passed” and showed good coverage but did absolutely nothing for actually hitting the necessary cases...

test6554 8y ago

I have some code I inherited that I have rewritten it twice now and the second time is when it really became stable and also easier to work with.

walshemj 8y ago

Or you rewrite it to be more flexible and seriously think about what if's eg what if sales tax was changed in the middle of a month/billing period. This is a real example at one job in the UK on budget day I used to listen the budget speech live in case it had any impact on the system I worked on.

ruok0101 8y ago
I worked with one guy once where he wanted the "ultimate flexibility" and every data model object basically became a database table with the columns 'key' and 'value'. Trying to think of everything ahead of time has its own problems...
- walshemj 8y ago
  Which is how map/reduce systems work at the core - and how we implemented it back in the 1980's. Each record type and field in that record had its own entry in a MIDAS table so you could process say TELEX records differently to Email, Data etc.