n.V6-2.01 | A Layman Writes the Tech Volume
01| I do not know how to build this thing. Let me get that out of the way on the first page of the volume that is supposed to explain how it gets built.
02| I do not know blockchain. I have no informed opinion on databases, on EdTech stacks, or on whether this should run on one cloud or three. I have read enough to sound dangerous at a dinner party, which is precisely the level of knowledge that kills projects. A founder who half-understands the technology makes confident decisions in a field where his confidence is worthless, and the people who actually know are too polite to say so until the money is spent.
03| So why write this volume at all? Because there are two jobs here and only one of them is technical. The first is deciding what the platform must do for the people who use it. The second is deciding how to make it do that. The first job is mine. The second belongs to people who know what they are doing, and the worst thing I could do is take it from them by pretending.
04| That is not a hedge. It is how every serious build works. A client who tells his architect I want a house that holds its heat in winter and I do not want to hear the neighbours is doing his job well. The same client telling the architect which insulation to specify is doing his job badly, and he will get a worse house for it. My job is the first sentence. Somebody else's job is the wall.
05| So this volume states wants. Every chapter runs the same shape. Here is what we want. Here is what people who know this work say a want like that takes. Here is what we give up to get it.
06| That third part is the honest part, and it is the part that usually goes missing. In engineering there are no free wins. Everything you want costs you something you also wanted. More robustness costs you top speed. More flexibility costs you stability. Simpler tools cost you power at the top end. A platform that survives a dropped connection shows you older data than one that does not. Anyone who tells you they got all of it at once is selling something.
07| I can make those calls, because they are judgments about people rather than about machines. Whether a Maveriq should ever lose an afternoon's work because a line dropped is not a technical question. It is a question about what her time is worth and what a broken promise does to her willingness to try again. I have spent years thinking about that. I have spent no years thinking about conflict resolution in distributed databases, and I am not going to start now and call it expertise.
08| Where I have not decided, I will say so plainly rather than write a balanced paragraph that pretends the decision is made. A book part full of on-the-one-hand is a book part that decided nothing and admitted nothing.
09| There is a real risk in this approach and it is worth naming. A layman stating requirements can state impossible ones. He can want robustness and speed and flexibility and cheapness in the same sentence and not notice he has asked for a square circle. That is what the middle term is for. Before a want gets written down, it gets checked against what the field says such a want actually requires — and if the answer is you cannot have both, then the chapter has to choose. That check is the difference between a brief and a wish list.
10| Which is what this volume is. Not a specification. A brief. It tells whoever eventually builds this what the thing has to do, what we refuse to give up, and what we are willing to lose. Then it gets out of the way.
11| One more thing, because it will come up. Somebody will read this volume and conclude that a man who cannot specify his own platform has no business designing one. Fair enough. My answer is that the anti-poverty industry is full of people who can specify the technology perfectly and have never asked the person on the receiving end what they actually need it to do. I would rather be wrong about the stack than wrong about the human being. The stack can be replaced in a year. The human being walks away and does not come back.
