Throwaway Analysis Tool

DRAFT

Context

You are assessing a problem such as a bug, a performance problem, or a security issue, and you are facing a problem that is not understandable.

Problem

How can you advance the assessment effectively?

Forces

The goal of an assessment is to find answers as quickly as possible. Custom tools help make analyses faster, while generic, “reusable” tools can make it more difficult to find the answers you need.

Solution

Build a dedicated, throwaway tool just for your problem.

Use a Contextual Playground to prototype a visualization or to explore the result of a quick query.

The focus should be on finding an answer. Reusability should only later become a concern.

Some tools can indeed become reusable as a Custom View, Custom Search, or Custom Action, but that should not be the driving force.

When you start with reusability in mind, you tend to favor generic tools. However, assessment benefits from contextual tools. Focusing on the context first speeds up the overall effort. To make this economically feasible, the cost of the tool should be amortized on the first use. You can make this possible through a Moldable Tool.

\begin{figure}[h] \includegraphics[width=\columnwidth]{throwawayQueryTool} \caption{A throwaway analysis to find candidate examples.} \label{fig:throwawayQueryTool} \end{figure}

A throwaway analysis tool should be cheap to implement. For example, below we see an ad hoc query to find Lepiter Project Diary pages that match the string “Ludo” and also contain Example Object snippets, to illustrate the use of example objects in documentation.

(LeDatabase gtBook pages
	select: [ :page | page asMarkdownString includesSubstring: 'Ludo' ])
	select: [ :page | 
		exampleSnippets := page
				deep: #children
				select: [ :child | child isKindOf: LeExampleSnippet ].
		exampleSnippets notEmpty ]
  

Throwaway analysis tools may appear to be wasteful: they cost development effort that you do not get to reuse. However, the goal is to optimize the overall development speed. The alternative to custom tools is manual exploration.

Building a tool, even for just one usage, can outcompete manual exploration by a large margin. That budget difference can more than make up for the cost of the tool development.

Consequences

By making it cheap to build analysis tools, tool-building becomes an essential part of the development process, rather than a side activity, just as writing tests has become an integral development activity rather than an add-on.