Software developers spend much of their time making decisions from system data, yet they still extract that information through manual code reading.
2
Moldable development creates a custom view or tool for each question, so developers can inspect structured software data instead of scrolling through text.
3
Glamorous Toolkit applies this approach across systems and workflows, including React Native dependencies, Ruby applications, Jenkins pipelines, and console logs.
Summary
Tudor Gîrba argues that code reading remains an unexamined source of waste in software development. Developers read code because they need information for decisions, so he treats software as structured data that can be queried and presented through useful views. Moldable development means starting with a question, checking whether the right tool exists, and building one when it does not. In Glamorous Toolkit, objects can be shown as pictures, paths, data structures, or other views rather than through one generic inspector. Gîrba demonstrates querying a React Native package.json to count dependencies, exploring component relationships to find cycles, and inspecting a Jenkins pipeline with project-specific log highlighting. The approach applies across languages and frameworks because the views are built around the question and the structure of the system. Gîrba also connects the idea to feedback loops: when custom tools become cheap to make, teams can change how they understand systems and make decisions about them.
Code reading is really decision-making from system data
Gîrba says developers do not read code for the act of reading. They read it to figure out what to do next, which makes code reading part of decision-making. He points to research dating back to 1979 and says developers still report spending about 50% of their time reading code. That long-running problem has received less attention than other development activities. Since reading is the most manual way to extract information from data, he argues that software development should use the structure already present in software to get information more directly.
Better-written code cannot solve understanding at system scale
When Demetrios Brinkmann asks whether comments or cleaner code could solve the problem, Gîrba rejects that idea. The same code can produce very different results for two people in both speed and accuracy, so understanding cannot depend only on the code itself. He also points to legacy systems such as COBOL unemployment systems that remain difficult to replace because teams cannot fully understand or change them. Clean code and modularization still matter, but they do not remove the need to reason about large, changing systems.
Moldable development changes the view instead of forcing every problem into one tool
Gîrba introduces Glamorous Toolkit as a moldable development environment. Its inspectors can show the same objects through different views. A generic view exposes variables and values, while another view can make an object look like a folder, picture, file-system path, data structure, or algorithm. He says every experience of a software system passes through a tool or projection. If that projection is under the developer's control, the developer can choose a form that matches the question instead of accepting one generic layout.
A developer can build the missing tool directly from the question
While inspecting a React Native package.json, Gîrba asks how many dependencies exist and how many do not begin with React Native. He parses the JSON into a dictionary, extracts key-value pairs, selects keys beginning with React Native, and counts the results. He describes the workflow as starting with a question, asking what tool would answer it, and building that tool if it is missing. The point is to use scrolling only for orientation. Eyes are good at spotting patterns, while code should do the counting and selection.
System models expose relationships that text browsing hides
For a React Native application, Gîrba turns JSON into a model and then into a graph of linked components. The team built this after encountering cyclic dependencies between React components. A custom view extracts components, shows their source, and renders which components embed other components. Clicking through the relationships reveals the dependency cycle. The same technique applies to higher-level structures in other frameworks, since looking only at source text can miss conventions and relationships defined by the framework.
The approach is independent of language and framework
Gîrba shows a Ruby on Rails system after demonstrating React Native. He says the same method can work in Ruby, Python, Go, or other environments. The important unit is the structure that needs to be understood, which may be a framework-level construct rather than a language-level file. A Ruby on Rails application contains conventions and framework behavior that a developer would miss by looking only at Ruby code. Moldable views can be constructed for those higher-level structures.
Gîrba says customization only works if a tool can be created quickly. If each view takes days, the method is too expensive. If it takes minutes, a team can build a tool for one project or even one use and discard it afterward. He compares this cost change with testing, mobile apps, and DevOps. When deployment becomes much cheaper, teams can change their feedback loop and release more often. He expects a similar effect when teams can cheaply create views for questions about their systems.
Moldable views can bring operational data into the development environment
Gîrba applies the idea to a Jenkins deployment pipeline. Instead of using the same web interface as every other project, the team brings the pipeline data into its own environment and creates a meaningful view. A pipeline map shows stages, a failed stage can be opened, and the console output for that step can be displayed with project-specific highlighting. He then opens the source of the console view, finds its styler, and edits the highlighting logic in place. The view itself becomes something the team can inspect and change.
"I'm simply going to refuse to scroll through any piece of text because when I scroll through text I will use my eyes as the data mining tool."Tudor Gîrba27:48
Who should watch
You spend a large part of development time browsing unfamiliar or legacy code and want a faster way to answer specific questions.
Your team works across application code, framework structures, and deployment pipelines, but each tool gives you a fixed interface.
You are evaluating whether custom visualizations and lightweight analysis tools could help developers understand system behavior without building a general-purpose product first.
