The Research and Development department would appear to give equal weight to both research and development by virtue of naming, yet there are few engineers who would claim that research is a primary responsibility of their job. Between working on product features, planning sprints, fixing bugs, and attending meetings there is little time left for research. But what is the cost of foregoing research in favour of development? In this article, I consider the economic cost of ignoring research and argue that focusing solely on development is harmful to both product and engineering.
In a basic economic growth model, we assume that there are limits to growth due to diminishing returns on capital. If we invest in a machine that increases output, output will increase — makes sense. If we invest more money in more machines, output will continue to increase up to a point. A common example is adding more people to a software team as a means of delivering product faster. At some point, adding more workers causes problems such as workers getting in each other’s way or frequently finding themselves waiting for access to a shared resource. This effect has been codified as Brooks’ law, stating that “adding human resources to a late software project makes it later”. This principle is not unique to software — the law of diminishing returns is a fundamental principle of economics.
A second fundamental principle of economics is depreciation. If we buy a machine to increase output, eventually that machine will break and need to be replaced. If we decide to increase the number of machines that we buy, we are also increasing the number of machines that will break in the future and need to be replaced. The money needed to replace the broken machine cannot be used to buy a new one.
There are two observations we can derive from what we’ve learnt so far. First, output increases at a declining rate due to diminishing returns of scale. Second, the cost of depreciation increases with investment. If the loss due to depreciation increases linearly and output increases at a declining rate, then at some point growth stops for an obvious reason: the cost of depreciation becomes greater than the return on investment. In fact, there is some maximum level of output we can achieve at which growth stops. Economists refer to this maximum level as the long run equilibrium.
We can relate this to software development by considering the relationship between feature development and tech debt. Whenever we develop new features (and increase output), we also take on future tech debt and software maintenance (and increase depreciation). Eventually, the rate of output matches the rate of depreciation and software development stagnates at an equilibrium.
Our basic growth model shows the limits we can extract from working harder. But it has a glaring weakness — it ignores the effect of innovation. If we add in the assumption that innovation increases the rate at which we can deliver output, we can produce a model with continual growth. The key to continual growth is the inclusion of an innovation multiplier that increases output given changes in the level of technological innovation. Intuitively, this makes sense: a more efficient machine can get more output given the same input.
Let’s add a third observation to the things we have learnt so far: innovation is the key to continual growth. Without innovation, our growth model reaches a limit, and your software project and organization will stagnate. With innovation, efficiencies in technology allow you to continue to grow past the point of stagnation. The key factor in an organizations continual growth is to increase innovation at pace with tech debt and depreciation.
Where does innovation come from? Research. With the wealth of access to online resources we enjoy today, the opportunities for discovering innovative solutions are far more accessible than they have ever been, and by dedicating time each week to research instead of development, we can discover innovative solutions to our problems, paving the way to continual growth.
[N]o matter what technology you use, or sprints or firing pistols, or whatever, the complexity will eventually kill you. It will kill you in a way that will make every sprint accomplish less. Most sprints will be about completely redoing things you’ve already done. And the net effect is you’re not moving forward in any significant way.
Rich Hickey — Simple Made Easy