透明思考

(From my chat history with Michael Robinson.)

(11:16:46 PM) xcqmichael: In your situation, it's important to understand that there are two ways of looking at software, the coder way and the business way.
(11:17:22 PM) xcqmichael: The coder says software is successful if all the tests pass, the code is well structured, and easy to understand and maintain.
(11:18:01 PM) xcqmichael: The businessman says software is successful if it delivers more value to the business than the business spent to create it.

(11:19:22 PM) xcqmichael: You separate them in terms of pain points.

(11:25:00 PM) xcqmichael: point 1:
(11:25:53 PM) xcqmichael: Refactoring stories (or other technical debt stories) are like any other kind of story; they should follow INVEST criteria, they should have an estimated effort, and they should have a prioritized business value.
(11:26:18 PM) xcqmichael: Because, in the end, it all comes down to cost to code vs. value to business.
(11:26:28 PM) xcqmichael: point 2:
(11:27:12 PM) xcqmichael: Refactoring, by definition, means making changes to the structure or organization of a code base without changing its functional behavior.
(11:28:06 PM) xcqmichael: When you have a code base that is fragile and has no test coverage, it is very costly to refactor because it is very costly to confirm you have not changed functional behavior.
(11:28:12 PM) xcqmichael: point 3:
(11:28:51 PM) xcqmichael: When the cost of a technical debt story is very high, then the business value must be even higher.
(11:29:44 PM) xcqmichael: Consequently, the worse the code looks to you from a coder point of view, the more you should leave it alone from a business point of view.
(11:29:51 PM) xcqmichael: point 4:
(11:30:27 PM) xcqmichael: Therefore, when someone says, "there's whole bunch of code needs to be refactored", probably, none of it should be.

(11:31:49 PM) xcqmichael: Well, it all comes down to prioritization.
(11:32:00 PM) xcqmichael: And a clear sense of the cost/value tradeoffs.