Thoughts about Ugly Pictures

Ugly, but useful pictures

We steer software development with visualizations. They nearly never look as nice as the ones we typically put on Keynote or PowerPoint presentations for the board. Missing legends, no great layout, lots of accessibility issues. Why do we do that?

Static vs dynamic

With GToolkit, the picture itself is only a static representation. In the integrated environment we add user interface to these pictures. We click on elements or hover over them to see detail inspectors and other views on the same element.

Hovering shows a micro-print, clicking an inspector with multiple tabs for different views

A legend of the picture is also easily within reach: a command-click on the tab showing the visualization shows the source code of its definition. And that can not get out of sync, like a static legend can.

The definition of a visualization, with the largestFilesFirst method expanded to show its definition

Information density

The pictures we make are helping us make decisions. We deliberately use our human pattern recognition abilities to show both the whole, and interesting details. As we often don't know yet what might be interesting, we show many different dimensions at the same time, and make the details so small, that we can still just discern the differences. The public for the ones we show here is the relevant stakeholders that need to make the decisions. They normally have background knowledge that we don't need to put in the picture, or a short verbal explanation of a few sentences is enough to help steer the decision.

Many different colors indicate that many different people have worked on something

Fast feedback cycle

These visualizations are cheap to make, they can often be made in 10 minutes. That makes them part of the inner plan-do-check-act (PDCA) development cycle, where we have an hypothesis about the system that we can quickly verify. We keep them if they help us later explain with perfect hindsight how we could have done ideal development, or if we need decisions by or explanations to other stakeholders. And yes, we can make them beautiful too.

Let me know if you want some help making ugly pictures to steer your development

Consul Democracy in 17 pictures

Yesterday, I was at FOST Amsterdam where Lucía Luzuriaga presented Building Digital Democracy: Code, Community, and Trust. She describes it as: As governments seek more inclusive approaches to decision-making, open-source civic technologies are playing an increasingly important role. Consul Democracy is one such platform, enabling participatory processes like consultations, participatory

GToolkitLauncher Code Analysis

We have been building up a growing collection of analysis tools that we use to analyze existing code bases and steer development. The existing workflow of starting GToolkitLauncher, opening the releases view, clicking to download the latest version, and then copying and inspecting multiple Metacello invocations to load the tools

The state of LLM Agentic Flows

Updated from an earlier posted on LinkedIn If this is state of the art at Cursor, I have some questions. The largest LLM generated Rust file in the repository is over 77000 lines. That is far too large, and shows that working with so many agents on the code base

Micro Prints for Micro Managing a Large Language Model

Prototypes are easy, but getting an LLM to generate maintainable code over a longer period of time is not. As the models are not yet good enough, we need a very short feedback cycle. Reading all the code doesn't scale, and we need another way to maintain trust