DRWN: Headless project management

The work never changed

Henry Gantt drew his chart in 1917: tasks, durations, dependencies. PERT followed in 1958, the Work Breakdown Structure in 1962, Microsoft Project in 1984, and Jira after that.

The logos changed; the three nouns did not — task, milestone, dependency. Hardware improved by roughly a factor of a million. The data entry stayed where it began.

We keep making “better buggy whips” — faster machines doing the old work. Alan Kay, OOPSLA 1997

DRWN does not ask for that data entry. It takes the raw input — the notes from a customer call — and drafts the tasks, the owners, and the conflicts it finds. The drafts are read and corrected where wrong.

Everyone speaks the tool’s language

To use a project tool, a team first translates its work into the tool’s words: epics, sprints, story points. A team building a cooking app thinks in recipes, ingredients, and batches, and has to set that aside.

Kenneth Iverson won the Turing Award in 1979 for the argument that notation changes which thoughts come easily. Software engineering reached the same conclusion and named it domain-driven design: write the system in the language of the business. Palantir frames it as “not in terms of rows and columns.”

The argument is largely settled. Project tools never adopted it.

Projects do not share a vocabulary, so DRWN does not impose one. It answers in the nouns of whatever project it is pointed at. For an equipment-training-simulation project, those are objects, simulations, and interactions.

One shape for every team

In 1962 Douglas Engelbart described an architect at a screen, calling up the building site, then an overhead plan, then a slice of the interior — the same structure, in whatever view the moment needs.

In 1979 Trygve Reenskaug separated the data from the view deliberately and called it Model–View–Controller. That separation shipped, but inside the code; the interface still shows a single view.

Most tools offer a grid, a board, or a Gantt — the same shape for a hospital and a game studio. Teams add extra boards to approximate the views the tool will not produce on its own.

DRWN renders a different shape for each question: a list for projects, a board for triage, a written briefing for a conflict, a table for finished work. These were not laid out in advance; the question selects the shape.

Reading instead of operating

In 2006 Bret Victor observed that most software is for reading rather than doing: “interaction is an essentially negative aspect of information software.” A project tool asks someone to click, filter, and assemble the current picture by hand — and the picture is out of date by the time it is assembled.

Six years later he added the other half: “creators need an immediate connection to what they create.”

DRWN answers the question rather than handing over the controls. A conflict between two tickets returns as a plain-language briefing a non-specialist can follow, with the technical detail kept separately for the team. It also shows its reasoning as it works.

It is not a chat box. The input is one line; the output is a full view.

Why this is possible now

None of this is new, which raises the question of why it never shipped. The answer was cost. A representation tailored to one domain, and kept current, was expensive to build, so vendors shipped one generic tool and left each team to adapt to it.

Ink & Switch describe a team whose flexible index-card system got worse the day it was computerised. Geoffrey Litt identifies what changed: turning a rough description into working software has become far cheaper than it was.

DRWN is a native desktop application; its output leaves as a real file — a PDF dragged onto the desktop, a link opened in the browser. It could not have been built two years ago; now it is a few people and a few weeks.