“Developers spend most of their time figuring the system out."

Let’s dissect this a little.



1/

The oldest reference on the topic I know of dates back to 1979:

Zelkowitz, Shaw, and Gannon. Principles of software engineering and design. Prentice-Hall Englewood Cliffs, 1979.

2/

It said that most of the development time was spent on maintenance (67% in the book).

Granted, the book does not specify how the figure was obtained. Still, it was deemed an important enough problem to attract significant research attention since then.

3/

So, how far are we now, more than 4 decades later?

Let’s look at this recent paper:
Xia, Bao, Lo, Xing, Hassan, & Li. Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering, 44, 951-976.

4/

This paper describes in great details how the figures are obtained.

And it says that Comprehension took on average ~58%.

Now, take a closer look at the third column in the table: it says Navigation (24%), and that is considered separately from the Comprehension effort!

5/

So, after 4 decades, we can observe that not much has changed beside learning how to measure the “figuring out” time.

So what?

Well, that is the single largest expense we have. If we want to optimize anything in our discipline we should look at this part first.

6/

We talk often about how we build systems, but how often do you talk about how you spend the “figuring out" time?

If we do not talk about it, it’s not explicit. If it’s not explicit, it does not get optimized.

7/

If we do talk about how the “figuring out the system” time is spent, we notice that people spend it reading.

In fact, as the above paper also shows, comprehension is essentially measured as reading! The two are considered as mostly synonymous.

https://twitter.com/girba/status/1330247327668383746?s=20

8/

So, how should we talk about how we figure the system out?

Given that not much happened for 4 decades, we should entertain the idea that maybe we should frame the problem differently.

Please, bare with me. This is where it gets interesting.

9/

So, why do developers read code?

Because they want to figure the situation enough to know what to do next. The intent is important. This is decision making.

From this perspective, reading is just the means through which information is gathered from data.

10/

Now, before you can do something significant about anything, you have to name it. Otherwise it's like with Voldemort.

So, many winters ago, I called the “figuring the system out to know what to do next" effort assessment. And I said we should optimize development around it.

11/

For a whole decade my colleagues and I explored this idea. And it led us to #MoldableDevelopment.

What’s that?

Reading is the most manual way to extract information out of data. It does not scale and leads to incomplete information & uncertainty.

https://twitter.com/girba/status/1175287876818493440?s=20

12/

Software is hard enough. Not knowing what the current system is like should not be an acceptable variable in the equation.

A hand drawn picture about the current system is a belief. Decisions should not be based on beliefs. Not in engineering.

https://twitter.com/girba/status/1352255981464522756?s=20

13/

So, how does #MoldableDevelopment work?

Once we accept that systems are data, it becomes obvious we should approach it like data, too. How do we do that?

Data science tells us that you first start from the problem and then reason through a tool that matches the context.

14/

The key idea of #MoldableDevelopment is that the tool is custom built after knowing the problem. Hence it’s contextual, and because of it, it can take care of the boring part of reading.

Of course, for this to be practical, the cost of creating custom tools must be small.

15/

I see the flow of constructing custom tools during development, and, ideally, for every single development problem, as the next major leap in software development.

https://twitter.com/girba/status/1286779589709234182?s=20

16/

In a decade from now, we should not be measuring the "figuring the system out” in terms of reading. We should occupy our energy with solving actual problems.

To get there we should start by talking about how not to read code.

We cannot afford not to.

17/

We created #gtoolkit to provide a concrete start for the "how not to read code" conversation.

Go to http://gtoolkit.com . Play with it. Feel #MoldableDevelopment.

And engage with us:
http://discord.gg/FTJr9gP 

Let’s make that conversation happen.

18/18