Feenk, the folks behind Glamorous Toolkit posted a blog 
> Developers spend most of their time figuring the system out.
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.
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.
For a whole decade my colleagues and I explored this idea. And it led us to what we now call moldable development.
Once we accept that systems are data, it becomes obvious we should approach it like data, too. Data science tells us that you first start from the problem and then reason through a tool that matches the context.
As software is highly contextual we cannot predict specific problems. We can only predict classes of problems. To handle this, the key idea of moldable development is that the tool should be moldable after knowing the problem. In this way it can deal with what's important in context, 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.
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.