1. I want you to build me a borgizaf. How long will it take you and how can I measure your productivity? Now I want you to change the following line of code to print "bye" and answer the same two questions.
`console.log("hello");`
Any answer to the first question has a certainty of 0%. The answer to the second is almost 100% certain. The certainty is directly dependent on whether you know what you are building AND whether you have direct experience having completed the same tasks.
2. Given some task that is to some extent unknown (see above), how do we proceed? We reduce the uncertainty/degree. This leads directly to "hello world". You start with a program that shows what a borgizaf can do and show it to the people who want it. If it is wrong, evolve it. Iterate.
The problem here is that often the people who want the borgizaf can't really tell you what it is. Especially if it has not been made before. But they can tell you what it is not. (See Notes on the Synthesis of Form). Even the people who want a borgizaf may not know what it is. And it may change.
3. In order to increase "productivity" we often have teams of people working on aspects of the same problem. After years of labor each part is done and one day the thing is assembled. Unfortunately, the drive team did not tell anyone they were using front wheel drive, and everyone else thought it was rear wheel drive. Left and right driver position, etc. You don't believe this is possible. One word "Ingres".
Iteration must be the whole. Unless you are iterating on the whole, your certainty will always be 100%. Because the pieces might not fit together.
4.The speed at which you develop a borgizaf, is the dependent on the speed of iterations and the degree to which each iteration reduces uncertainty.
It's a bit worse than that. The borgizaf is often defined by business development, or somebody like that. They decide they need one after a bunch of customer interviews. But the customers don't actually know what they need. So the business development people are trying to describe something that the users need but don't know that they need, and that doesn't yet exist.
Yeah, the main problem is uncertainty, not lines of code to write. You measure progress mostly by how much you reduce uncertainty.
Yes. Often the need is best understood through iteration, but certainly having "eyes on" by the ultimate customer helps. Once I was told by marketing that security was not important. The customers got a prototype and screamed bloody murder. I think the moral of the story is to view the development of a product as a collaboration between all parties. All, including customers.
If there are silos of concerns then you can end up with a beer distribution game.
And this: "You measure progress mostly by how much you reduce uncertainty." is very succinct
The iterative approach described here to finding a 'good' borgizaf is simulated annealing. Make an initial guess to the solution, then start with changes that are large early on and which increasingly refine as you get closer to your goal.
Metropolis-Hastings algorithm works better for situations for which you know even less about what a good borgizaf looks like. Perform many experiments (code changes) and toss out all of the ones that don't work. Science works this way. An automated LLM coder would probably also go this route as the cost of trying many things would be more heavily automated.
Large systems tend to look more like the genetic algorithm. The space is diced up into individual components and then each 'gene' is optimized in parallel. For example if you were trying to build a Linux distribution you'd have several hundred packages and then for each release the packages could improve or be entirely replaced with better versions (or swap back and forth as they competed).
Of course there are other search strategies that can be employed. Search is still an important area of research.
Sure, everything is an optimization problem, the hard part is defining your cost function, especially if the borgizaf is trying to solve an ill-formed business problem.
1. I want you to build me a borgizaf. How long will it take you and how can I measure your productivity? Now I want you to change the following line of code to print "bye" and answer the same two questions. `console.log("hello");`
Any answer to the first question has a certainty of 0%. The answer to the second is almost 100% certain. The certainty is directly dependent on whether you know what you are building AND whether you have direct experience having completed the same tasks.
2. Given some task that is to some extent unknown (see above), how do we proceed? We reduce the uncertainty/degree. This leads directly to "hello world". You start with a program that shows what a borgizaf can do and show it to the people who want it. If it is wrong, evolve it. Iterate.
The problem here is that often the people who want the borgizaf can't really tell you what it is. Especially if it has not been made before. But they can tell you what it is not. (See Notes on the Synthesis of Form). Even the people who want a borgizaf may not know what it is. And it may change.
3. In order to increase "productivity" we often have teams of people working on aspects of the same problem. After years of labor each part is done and one day the thing is assembled. Unfortunately, the drive team did not tell anyone they were using front wheel drive, and everyone else thought it was rear wheel drive. Left and right driver position, etc. You don't believe this is possible. One word "Ingres".
Iteration must be the whole. Unless you are iterating on the whole, your certainty will always be 100%. Because the pieces might not fit together.
4.The speed at which you develop a borgizaf, is the dependent on the speed of iterations and the degree to which each iteration reduces uncertainty.
Really, I think that is all there is to it.