Why software projects take longer than you think: a statistical model (2019)
Start from an empty file and write to an imaginary API or pseudocode what you actually want to do and coding is easy and fast!<p>I think the high level imaginary API&#x2F;pseudocode of any system is straightforward and fast when you start from scratch. (Because you&#x27;re not focused on detail and just intent)<p>But when you start from an existing codebase, existing infrastructure, existing APIs, it slows to molasses. You&#x27;ve got to understand and have a mental model of ALL OF THAT before you can complete your intent.<p>I think this is why software takes longer than expected. Your mental model has to be accurate, and there is always more to learn.<p>How do you solve the problem?<p>I&#x27;m an advocate and trying to design what I call &quot;commutative programming&quot;, which is another way of saying that the behaviour is the product of every statement about the behaviour that is desired, not an explicit instruction of what to do next which is what modern programming is and it is slow and tedious and doesn&#x27;t compose. In this dream, if you want to change behaviour, you just add statements. Programming is additive! Not edit sourcecode or try to find out where to insert your lines of code or tweak existing lines. Let the computer tell you about conflicting requirements or missing criteria.<p>We need query engines and cost based optimisers for behaviour.<p>Imagine taking lots of files that are simple &quot;writing to an imaginary API&quot; - that&#x27;s your intent specification. You just need to merge them together and your system is finished.<p>I started work on a commutative GUI <a href="https:&#x2F;&#x2F;github.com&#x2F;samsquire&#x2F;additive-guis">https:&#x2F;&#x2F;github.com&#x2F;samsquire&#x2F;additive-guis</a> but I&#x27;m also thinking from time to time about commutative code where we define refinements to desired behaviour and the computer behaviour query engine or rule engine generates the code or configuration that exhibits this behaviour. (A bit like Kubernetes for behaviour.)<p>In the future: we don&#x27;t get LLMs to code for us, but we have highly expressive semantic vector spaces that map to architectural relationships and meaning of behaviour, and changing the architecture of a system to support new behaviour is a matter of changing the serialisation of semantic vectors via the prompt.