Useful Before Complete

A tool can be unfinished and still make someone’s day better. It might do one job for one person, need a little explanation and have no ambition to become a platform. That can be enough.

The useful question is which parts can remain unfinished. A tool might handle one kind of input, leave the final wording to its author or run only when someone needs it. Those limits can make a first version easier to build and understand while preserving what the job depends on.

Some useful things never justified a software project

People tolerate small recurring frustrations because getting software made can involve more work than the frustration seems to deserve. They search for the same information, reconcile the same files or rebuild a familiar explanation. None looks important enough to compete with the roadmap.

AI-assisted building gives us more room to address those problems directly. A person who knows the task can work with an assistant or a colleague to make a first version, try it and change it while the need is still in view.

The question becomes concrete: did this help with the job? A rough first version can answer that better than a presentation about what a comprehensive solution might eventually do.

It can also reveal that software was not the missing thing. Perhaps the relevant information needs a clear home. Perhaps two people need to agree what a field means. Finding that out is a useful result, even if it leaves us with very little to build.

Incomplete scope is different from unreliable work

A draft-writing tool can leave the final wording to its author. A comparison tool can show differences without deciding what to do about them. A local script can require someone to provide the files each time instead of maintaining a live connection to another system.

Those are deliberate limits. They keep the tool small while leaving responsibility where a person can exercise it.

The important question is what happens when it is wrong or unavailable. Can the person recognize the mistake? Can they correct it? Can they continue the work another way? A tool whose failure creates an hour of inconvenience is a different proposition from one whose plausible answer leads someone to make a decision they cannot undo.

Cheap rebuilding does not make every failure cheap. Lost information, a customer given the wrong answer and work silently skipped can matter long after the code has been replaced. We need to understand the consequence in the particular job, rather than borrowing a reliability number from another kind of system.

Often the answer is simple. Keep the original files. Show the source beside a suggestion. Make the action a person takes visible. Avoid doing work the tool cannot reliably account for. These choices can be part of the first version without requiring a ceremony around it.

Responsiveness has value

A modest tool that helps this week can be more useful than a sophisticated one that arrives after the need has changed. Waiting has a cost: people keep doing the awkward work, postpone something worth doing or invent a workaround nobody else understands.

That does not mean every request should produce another app. The new tool also asks something of people. They have to learn it, check its output, remember that it exists and deal with changes. A collection of tiny conveniences can become a fairly large maintenance problem.

We therefore want to see whether the whole job improves. Saving the writer ten minutes while giving three reviewers twenty minutes of plausible nonsense is poor arithmetic, even if the writing tool is very impressive.

A team using AI to prepare recommendations could agree that the sender reads the draft, chooses a recommendation and links the evidence before asking for a decision. That leaves colleagues a real question to resolve together. Forwarding six generated alternatives with “thoughts?” is a remarkably efficient way to become someone else’s workload.

Sometimes the improvement is speed. Sometimes it is confidence, fewer interruptions, a better question or the ability to do something that used to require asking someone else. The person doing the work should have a say in what counts as better.

A small tool does not promise a large one

A useful tool can stay local, be adapted by another team or become something people depend on more widely. Its next version should respond to that use. A successful demonstration does not commit anyone to building the largest system they can imagine.

Our Emergent Software Development essay describes how people can shape that direction through use, and how a workbench can either remain small or supply the working material for a more durable service. A tool can succeed without growing.

Start where someone can tell the difference

The useful first move is usually a recurring task close enough to a person that they can judge the result. Work with them, make something they can try, and listen to what becomes easier and what becomes harder.

The standard is appropriate usefulness. We should be able to leave a tool small without apologizing for it, and take its consequences seriously without turning it into a program. Both require judgment about the work in front of us.