Developers spend most of their time understanding the system
I’m often asked what I mean when I say “most of the time developers are tinkering with the system”. Let’s unpack this statement.
The oldest reference to this topic is in the book by Zelkowitz, Shaw, and Gannon. Principles of software engineering and design 1979. It says that most of the development time is maintenance (67%).
Software development costs (1979). Requirements – 3%, specifications – 3%, design – 5%, code – 7%, unit testing – 8%, end-to-end testing – 7%, maintenance – 67%
The book does not specify how these numbers were obtained, but it turned out to be a serious enough problem that it has attracted substantial research attention ever since.
How far have we advanced in more than four decades?
Take a look at a recent article by Xia, Bao, Luo, Sin, Hassan, and Li Measuring Program Comprehension: A Large-Scale Field Study with Professionals, published in IEEE Transactions on Software Engineering, 44, 951-976, 2018. This article is interesting because it details how her numbers came about. And it says that Comprehension spent an average of about 58%.
Let’s take a closer look at the results table.
Software development costs (2018)
In particular, take a look at the third column of the table: it says that navigation (Navigation) requires 24% of the total labor costs, and this is counted separately from the labor of comprehension (Comprehension)!
So, four decades later, we see that apart from finding ways to measure the time for “understanding”, almost nothing has changed.
So what?
Well, that’s the factor that takes the most time. If we want to optimize something in our discipline. then you have to look at it first. We often talk about how we create systems, but how often do you talk about how you spend time understanding the system? If we don’t talk about it, it won’t become clear. And if the factor is implicit, then it is not optimized.
If we study how time is spent “understanding the system”, then we understand that developers spend it reading. In fact, as the article mentioned above also shows, comprehension is, in fact, measured as reading! These two concepts are most often considered synonymous.
So how do we understand what “understanding the system” is?
Given that the situation has not changed much in four decades, we should probably interpret the problem differently.
And this is where things get interesting. So why do developers read code? Because they are trying to understand the situation enough to know what to do next. Intention matters. And it is about making decisions.
The time of understanding is the time of decision
From this point of view, reading is simply a means by which information is gathered from data. At the same time, this is done in the most manual way possible, so there is an important chance for optimization.
We can’t do anything to something until we give it a name. Many years ago I called this effort to “understand the system so you know what to do next” analysis. And I said that we should streamline development by making it an important factor.
Analysis is the process of understanding the situation around the system enough to make a decision.
For about a decade, my colleagues and I have explored this idea. And this research led us to what today we call “plastic development” (moldable development).
What is it?
Reading is the most manual way to extract information from data. It does not scale and leads to incomplete information and uncertainty.
Software is complex systems. Not knowing what the essence of the current system is should not be an acceptable variable in the equation. A hand-crafted picture of the state of the current system is faith. And decisions should never be made on the basis of faith. At least not in development.
Once we accept that systems are data, it becomes obvious that we need to treat them as data. Data science tells us that we start with a problem and then we think of a tool that fits the context.
Tools must fit the context
Since context is extremely important in software, we cannot predict specific problems. We can only predict classes of problems. The key idea behind malleable development is that the tool should be malleable after we understand the problem. Thanks to this, he can work with what is important in context and take on the boring task of reading. Of course, for this approach to be practical, the cost of creating specialized tools should be small.
I believe that the flow of creating your own tools during the development process, and ideally for each development task, is the next important step in software development.
Ten years from now, we shouldn’t be measuring efforts to “understand the system” by time spent reading. We must direct our energies towards solving real problems. To achieve this, we need to start by discussing how we can stop reading code. We cannot afford not to refuse to read.
We created Glamorous Toolkitto provide a solid foundation for discussing how we can stop reading code. Glamorous Toolkit is a flexible development environment that allows you to create custom tools for software systems at low cost. Experiment with it. Experience Moldable Development.
