A long software project needs progress you can exercise

A long project benefits from intermediate results that its developer can run and examine. A growing list of completed implementation tasks can show activity while leaving the next useful decision obscure. Organizing some work around an executable result gives the developer a way to judge what now works, what remains awkward and what to do next.

That is an interpretation of a personal method, not a universal productivity finding. Mitchell Hashimoto's essay on large technical projects is dated 1 June 2023. Simon Willison revisited it on 28 December 2024, after Ghostty reached its first major release. Looking back in November 2026, the relevant question is how a developer gets feedback during work whose finished payoff is distant.

Make the next uncertainty executable

Hashimoto describes ordering work to obtain tangible results and using automated tests when early components have no graphical interface. His account includes terminal parsing and runnable demonstrations. It is his experience of maintaining motivation. It does not establish how much faster another person or team will finish a project.

Consider a hypothetical document importer. The final application may need authentication, storage and an administration screen. Its next useful intermediate result could be a command that reads one representative document and shows which fields were accepted or rejected. That result exercises the uncertain parsing behavior without requiring the whole future application to exist.

The important property is that the developer can interrogate it. A completed parser class offers limited feedback if nothing feeds it realistic input. A short command that exposes accepted fields and an intelligible failure can reveal an incorrect assumption. The result changes the next task from “continue building the importer” to a specific problem that can be inspected.

Choose the slice by the uncertainty it can retire. Starting with the easiest visible screen might produce pleasant motion while avoiding the difficult integration. Starting with an enormous end-to-end path might postpone feedback for weeks. A useful intermediate target is small enough to reach and substantial enough to make the following decision better informed.

Personal feedback has a different audience

A developer's runnable checkpoint is not automatically a stakeholder release demonstration. The developer may need to see rough output, internal failures and unsupported input. A customer needs an accurate account of what the product can do and what remains outside the agreed delivery. Those audiences can use related evidence without receiving the same presentation.

Mixing them creates pressure to polish the wrong thing. A rough command that answers a technical question may look unimpressive in a management meeting. A polished screen may impress an observer while hiding the unfinished operation behind it. Neither impression determines whether the developer learned enough to select the next task.

Keep release communication explicit about readiness. Showing a successful intermediate path should not imply that permissions, recovery and deployment are complete. For the business owner, the useful consequence is a clearer conversation about remaining uncertainty. It is not a promise that frequent internal demonstrations make the delivery date predictable.

Decide what survives the checkpoint

A runnable intermediate result also differs from a deliberately disposable prototype. A prototype can answer a design question using shortcuts that will be discarded. An intermediate slice can be part of the eventual system, even when its temporary driver is thrown away. The distinction should be recorded before someone treats the temporary arrangement as a production foundation.

In the importer example, the parsing rule might survive while the command-line display disappears. A fake storage adapter might help exercise the parser but supply no evidence about durable writes. The developer should name those limits so that an easy demonstration does not silently decide the final architecture.

This is also where overbuilding can obstruct feedback. A general plugin system may be unnecessary to learn whether one document type can be interpreted correctly. Deferring that abstraction is reasonable if it remains reversible. Deferring a requirement that changes the meaning or safety of the operation needs a different justification.

Some progress is deliberately invisible

The strongest counterargument is foundational work. A permission boundary, a recovery algorithm or a cryptographic component may require sustained reasoning before an appealing interaction exists. Forcing all progress into something visual can reward incomplete correctness and punish the work that makes the product trustworthy.

Use evidence appropriate to the component. A permission check can be exercised by demonstrating that an unauthorized operation is rejected. A recovery mechanism can have a repeatable failure case with a specified outcome. Some properties need an argument about the design as well as execution. A visible screen is not a requirement for meaningful feedback.

There are limits to fragmentation too. A developer may need uninterrupted time to understand a subsystem before deciding how to expose a useful slice. Demanding a demonstration on an arbitrary daily schedule can become another reporting burden. The method should help the person think; it should not require them to manufacture a performance of progress.

Leave yourself a useful next starting point

At a checkpoint, retain the input, the command or procedure and the observation that changed the plan. Record what remains unproven. That makes the result usable after a break, when remembering why a component exists can be harder than rerunning it. Keep the record proportionate to the uncertainty resolved.

For custom software development, ask for the next runnable result and the question it will answer. Keep that personal feedback loop separate from release coordination and prototype decisions. A long project becomes easier to assess when its intermediate results expose behavior, while correctness and readiness keep their own standards of evidence.