€10,000 to save €500: the true ROI of modularization
Why Modularization Should Be the CEO’s Obsession
I often say that if there’s one topic CEOs need to keep an eye on, it’s the modularization of the software or information system their company is developing. First and foremost because it’s a purely functional topic, related to your business, and therefore doesn’t require technical expertise—at least initially.
But also because, among all topics related to quality, this one is by far the most important. Of course, testing is important, but the magnitude of the damage caused by a lack of testing is much smaller. In other words, it’s better to have a well-modularized codebase that is poorly tested—or not tested at all—than a well-tested codebase that is poorly modularized (1).
Developing the modularity of an information system requires some time: identifying and then interviewing key business stakeholders, creating a map of functional modules (the established term being “contexts” in the sense of Domain-Driven Design), and generally a few iterations. Such a study will cost you between 10 and 20 K€, let’s say 10 K€ as a rough estimate.
Let’s talk about just that: the cost of modularization—and thus your willingness to pay, as CEO. Those who have already experienced large-scale refactoring of a codebase—when modularization wasn’t planned for—know the cost (both financial and in terms of opportunity) and generally don’t want to go through it again.
Let’s work together to estimate the accounting cost.
The lack of modularization: a ticking time bomb
Let’s consider a typical application, the kind we see in abundance in all kinds of organizations: an application built by three developers over two years. The result is a nice plate of spaghetti—not the comforting kind you’re about to enjoy for lunch, but rather the antipattern resulting from a lack of expertise, constant urgency, and high turnover.
3 developers, 2 years, 1 plate of spaghetti.
Now the problem is glaringly obvious: bugs are popping up left and right, development timelines are spiraling out of control—in short, an unstable application. You decide to carry out the necessary refactoring and bring in people other than those who created the product (2).
How much will it cost you?
-
Conservative estimate: 1 full-time person for 1 year. Let’s be conservative and assume a freelancer at €450/day (excluding tax) for 200 days (~5 years of professional experience; I doubt you’ll find someone at that price who’s capable enough to handle such a project, but anyway, that’s our assumption). That comes to €90,000. An equivalent salaried employee would cost at least €50,000 gross, which means a cost to you of €70,000 (x1.4). The order of magnitude is therefore the same: €100,000, using a conservative estimate.
-
High-end scenario: there’s really no limit, as the cost of refactoring can actually exceed that of the initial development (3). Let’s assume two people working for two years: a senior developer paired with a less experienced one. As freelancers, let’s say €700 (excl. tax) per day for the first and €450 (excl. tax) per day for the second, for a total of €460,000. As employees, these same profiles would cost you 80,000€ and 50,000€ gross, for a total of 360,000€. The order of magnitude hasn’t changed, but it’s still four times the low-end estimate.
-
And the worst-case scenario—which we must still consider, as we’ve seen time and again—is that your software and your company won’t recover, because you’re not alone in the market.
The ideal time to modularize: on day one
In reality, many developers will agree with me that between code that works “quickly thrown together” and code that is robust at runtime and capable of evolving over time, the ratio is far greater than 1 to 4. And that’s starting from scratch; when building on existing code, refactoring can cost you a good 10 times more than the initial development.
Whereas a simple modularization study conducted at t0, on paper, even before a single line of code has been written, will cost you 10 to 20 K€.
This topic is a perfect illustration of the Dunning-Kruger effect: you need to know enough to realize that you know nothing. The youngest entrepreneurs have generally never heard of modularization and charge headlong into years of accumulating technical debt.
Those who, on the other hand, have already run into this problem and been forced to shell out such large sums of money know how important it is to plan ahead. May this article convince you to take the initiative so you never have to go through such a refactoring 😊
(1) This raises a troubling question: how can you properly test a poorly modularized codebase? If it’s poorly modularized, there’s a good chance that most of the tests will be high-level—for example, end-to-end tests—which goes against best practices (it’s generally recommended to build a test pyramid).
(2) Necessarily people other than those who produced the existing code, because if they had the expertise to carry out this refactoring, the codebase wouldn’t be in this state.
(3) You might then ask me, “Why not start from scratch?”—and you’d be right. Except that you want to avoid at all costs launching a refactoring project in parallel with production, because any code that isn’t in production is code on hold. The task is therefore very much like refactoring.