Questions before starting a project

ten of them, half an hour, an evening saved

What it is

The chapter's closer and its one practical outcome: a list of questions worth answering before the first line of code. Not because that is the proper way, but because each of them costs dearly if you answer it a month later.

Half an hour with this list turns a request to an AI from "make me a bot" into a mini-spec (article 3.15), which can produce a predictable result.

The ten questions

1. What does the program do, in one sentence? If the sentence won't form, the project hasn't been thought up yet, rather than "not written yet".

2. What is stored? A list of nouns. Tables and models come out of it (article 13.1).

3. Where is it stored? Memory, a file, SQLite, a database server — and the sign by which the chosen one will stop being enough (article 13.3).

4. Who uses it, and how many of them? Just you, ten acquaintances, or unknown people from the internet. Everything depends on the answer: authentication, load, handling other people's input, the cost of a mistake.

5. What can't be lost? Data splits into two piles: what can be gathered again and what can't. The second pile needs an answer about backups — on day one, not after the first loss.

6. Which external services are needed, and what happens when they don't answer? Every external API fails to answer one day. The options: show old data, show an error, retry later. The choice has to be made in advance, or chance makes it.

7. What changes most often? The message texts? The calculation rules? The appearance? What changes often should live separately and change without editing code.

8. How many environments, and where are the secrets? One machine, or a machine plus a server; how the keys get there (article 13.4).

9. How does it start, and who restarts it if it dies? "I do, by hand" is a fine answer for an evening's script and a poor one for a bot people use.

10. How will I know it broke? Logs, a notification, a liveness check. Without an answer to this, breakages are reported by users — or not reported, and they simply leave.

What to tell the AI

This list is convenient to work through with an AI — it asks good clarifying questions when asked outright to (article 3.11):

The idea: <describe it in two or three sentences>.
Ask me one question from the list at a time and wait for the
answer before moving on to the next:
1) what it does, in one sentence
2) what is stored
3) where it's stored
4) who uses it and how many
5) what can't be lost
6) external services and behaviour when they fail
7) what changes most often
8) environments and secrets
9) starting and restarting
10) how I find out it broke

Don't write code. At the end, gather the answers into a
mini-spec.

The resulting mini-spec is what a normal project starts from. The architecture brief (article 13.5) is assembled from it too.

Here are my answers to the ten questions: <text>.
Which decisions follow from them by themselves, and which
have I not made yet? The latter as a list, with the options
and one line of consequences per option.

What to look for

The questions were asked and the answers weren't written down. A week later all that remains is a general impression.

The AI answered the questions. It can propose options, but the choice is yours (article 1.1): these are precisely the decisions that aren't redone later.

"I'll work that out later" for questions 3, 5 and 8. Storage, backups and secrets cost the most "later".

A mini-spec written but never used in requests. Then it isn't a spec, it is a diary.

Cheat sheet