jasona.work (12/22/2014)

---

Stefan Krzywicki (12/22/2014)

---

Steve Thompson-454462 (12/22/2014)

---

Stefan Krzywicki (12/22/2014)

---

Steve Thompson-454462 (12/22/2014)

---

---

Brandie Tarvin (12/16/2014)

---

But still... To my mind, since I'm already fixing one part of the package, why shouldn't I proactively fix the rest of it to make sure the other 6 procs and ETL paths do NOT become a problem down the road?

Or am I just being too efficient?

I'm in your corner, Brandie. In my experience opportunities to pay down technical debt through refactoring can be so difficult to come by (getting approval for them, finding time for them, etc.) that when the window is open you should try to cram as much through as possible. I suppose one consideration might be the scope of the testing required before the changes can be released into production, but if the code is passing all tests why not release it?

When did we all start calling rewriting/reworking code "refactoring"?

I'm using that term here to describe changes to a code base that affect/improve the implementation but do not change the result/output. Per Martin Fowler (http://martinfowler.com/books/refactoring.html) it usually consists of a series of small changes so maybe applying it to large overhaul of a system is bit of a misnomer.

I'm just hearing it all the time now about any code rewrite or mod & I don't remember hearing it before this year.

Perhaps you need to refactor your process of learning new buzzwords?

:hehe: