Inspired by J.B. Rainsberger asking, “What are the values of software?” in his talk, “The Economics of Software Design” at https://dev.tube/video/TQ9rng6YFeY , starting around 4:30 where he talks about how to answer this manager’s question:
“My manager gets angry when I refactor.
What should I do?”
And JBR says that you should say…
“I’m just trying to reduce volatility in the marginal cost of features.”
I don’t think this works for me. My problem is that it’s been my experience that it’s typical for the team or line managers I’m working with to insist that this is my problem, as a professional software developer — that as a professional, I should eat the cost or use professional techniques to make the volatility problem go away, so that he doesn’t have to deal with it. “That’s what I hired you for — to make good estimates. ‘volatility’ issues are your problem.”
So I find it more helpful to say, quite honestly, that…
The reason I’m doing refactoring is to reduce costs.
Now this is simple, direct, honest, and easy to understand. And reducing costs is something that they want. But they don’t believe me, because refactoring clearly requires time (and hence costs money) to accomplish, so it “can’t possibly reduce costs.”
Actually, it can. Because refactoring improves the structure of the code without changing its functionality. And this means that refactoring reduces the maintenance costs of the code, in the future.
“But I don’t want you making ‘investments’!”, says the boss, “I want you pounding out code!”
That may sound like a rational and reasonable objection. But if my boss makes it, then I have to conclude that therefore, we should not be developing software. We may as well cancel the project and walk away. Because software development is always inherently a process of making an investment now, by writing the software, in hopes of a return on investment in the future. If that’s not what we want, then clearly, writing software is the wrong thing for us to be doing.
What we need to be talking about is the rate of investment that we should be doing at each stage of the project. Near the start, we should be investing more heavily, so that we can reap the rewards of that investment through the largest portion of the project. Near each major deliverable, we should reduce risk and investment, for the benefit of the short-term goal.
Every working day, software developers like me make hundreds of decisions, to invest in improving the quality of the code, or to mortgage the future, for a short quick burst of productivity.
We often do ourselves no favor by saying that “refactoring reduces costs long-term, by making an investment, short-term,” because it’s easy for our boss to assume that “long term” means years, when, in fact, many refactorings provide immediate benefits that repay the costs within a very short time. I’m often looking at refactoring changes, or improvements, that have pay-off times best measured in hours, days, or weeks. Only the more ambitious process and tooling changes may require some number of months to recover the investment.
And nearly every investment you make that improves your productivity on the project, continues to provide benefits for the lifetime of the system.
I find this incremental decision making process more useful than the “do it well or do it poorly” choice that JBR offers the project manager, starting just after 12:00 in the video: For the same reason you can’t shift an organization directly from yearly releases to weekly releases, you also can’t shift an organization directly from the “bad curve” to the “good curve” — you have to make incremental change, to be successful.
I proposed more realistic formulas, from the COCOMO estimation model that a realistic range of costs to develop the software on a project would be from 3.2 * KLoC ^ 1.05 on the low end, and 2.8 * KLoC ^ 1.20 on the high end. As JBR explained in his video, the “good curve” starts “higher” (more costly), but do to the “gentler slope of the 1.05 exponent, we’ll find that the “bad curve” of the 1.20 exponent, while it starts lower, it quickly goes much higher, and the overall cost quickly becomes overwhelmingly more expensive.
My objective is to move the exponent from 1.20 down towards 1.05, in incremental steps, so that we will have sufficient resources to be able to produce half way decent software. This will also increase up-front costs, raising the constant factor from 2.8 up to something closer to 3.2. But this has little effect, relative to the compounding benefit of the process improvements.