Thursday 4 October 2012

Incompatible technical debt cutting

I really like the following statement:

This process [changing the aggression system] is necessarily imperfect, and we're inevitably going to find that some things are slightly easier and other things are slightly harder. This is regrettable, but we're absolutely not going back down the rabbit hole and re-complicating the new system to solve comparatively minor imbalances, because the overall cost is just not worth it.

Source: Introducing the new and improved crimewatch, EVE Online's developer blogs.

I like it because it involves:

  • Cutting back on technical debt;
  • There's a realization here that there's no need to keep a suboptimal implementation alive, even if it means a change for the customers too -- if the customer (and/or the dev team) essentially gets something better in return;
  • No fear! I experienced a lot of fear and uncertainty involving changing existing code, even if it had a good test coverage with good quality tests. They make the project rigid and feared. They certainly overcame that.

Bottom line is I wish more companies would think like that.

Sharp tools are locked down ...

... because no one likes the children in pieces.

Powermock can be useful in trying to handle legacy code, but I think our team made a big mistake by promoting it in an ongoing fresh development.

It allows us to just ignore certain obvious design problems. If we cannot test a code without major headaches, then we have an architectural problem that needs dire attention. Solving the test won't make the problem go away, and we'll have to face it again, possibly with smaller timeframe and a much bigger mess.

To reiterate, doing this in legacy code is fine by me. Doing it in code that we can actually shape and refactor easily -- and is not final or designed in a way that usually prevents testability -- is a major risk and the question "How can we fix this at the source?" is a way better solution than relying on powerful tools to do it for us.