> If you're optimizing for speed of initial delivery, rather than TCO, then any method with less planning delivers faster and costs less.

I feel like we are getting somewhere now. For some projects speed of initial delivery is by far the most important factor. Which is why it's so important to qualify your claims instead of using absolutes like "planning always results in..."

> However, if you assume your software lasts longer than ~year (as pointed out in my initial reference, and his much larger work "The Economics of Software Quality") then they perform much worse. The actual payoffs in most of his research is around 8 months of development.

Why would you assume that? Lots of software these days lasts far less than a year, and that's intentional. This is not the 1970s when building software was an expensive and rare thing. There are literally hundreds of millions of applications out there. And billions of dollars being pumped into startups, the vast majority of which will throw out their initial idea and eventually pivot when they learn what their customers really need. Learned by building quickly and delivering something that works well enough to get it in front of people to see how they actually use it and how different that is from what you had envisioned (or planned). What comes to mind is the cardboard box that the kids play with while the new toy it came in sits ignored.

> Being "quick" is basically a jab from Jones about agile project quality.

Why would it be? Unless you are heavily biased towards software always being high quality. Which shows a lack of flexibility and a lack of professionalism about optimizing for what is important to your client or employer. If your employer needs a project to optimize for initial speed, then focusing on quality and planning is unprofessional and irresponsible and putting your own personal preferences ahead of what the company has decided it should optimize for.

> My experience has shown the opposite for any project involving more than 1 person that a customer uses for more than a year.

I'd chalk some of this up to confirmation bias. But at least this far better than "always". At least we are starting to add qualifiers like "uses for more than a year"

> I guess I don't see how you manage a team, a project, a customer, or investors where you need to hire people based on work you need to do, if you're only planning out a few weeks at a time

You manage the team by focusing on building and learning from what you build. Let's say you plan for an easy build over a few months and hire 1 person. They start building and as a result of building a new market opportunity is discovered so new requirements come to the surface. Some of these requirements are difficult to implement and will require 10 people over a few months to build. But that is where the company now wants to pivot. How did your plan for hiring 1 person help you here? I'd say it gave you a sense of false confidence. What would be more professional and frankly more honest is to say "we don't know yet". That can't go on forever of course. The entire point of favoring building over planning is that in the course of building you should be reporting back on new risks discovered. And new opportunities. It's not all downside. When you have a plan to take six months to build something and it only needs a month, well Parkinson's law is nothing new so we all know it will take six months.

Lacking a plan, and with a focus on urgency and speed, you are forced to ruthlessly eliminate requirements. Since you will get something built in a few weeks the chances of you getting the thing you needed in a month are much higher than the six month plan. The exercise of delivering working software every couple of weeks gives you laser focus on what your core offering is.

> This is where I start to fall into saying things about professionalism, as to me the difference between a professional and an amateur is exactly this capital and risk management.

If your only tool for managing risk is extensive and detailed plans that must be constantly maintained and that do a poor job of optimizing speed over quality, then you are not being as professional as you could possibly be. There are more tools available for managing capital and risk than "let's make a detailed plan".

If you are employed by a company where the culture is all about using plans to manage risk, then you've found a great fit for yourself. But you shouldn't look down your nose at alternative ways of managing risk and call them amateur. There are different types of risk and there is no silver bullet in managing them.

One alternative for managing risk is admitting that you don't know and just building the damn thing and learning from it. This method of managing risk is especially important for really new things that have never been done before. You want to fail early and often and that is the most professional thing you could possibly do on those types of projects. At least until someone comes up with something better.

I'll just end by saying thank you for making the effort to steer this to a higher quality and more nuanced conversation. I enjoyed talking about this with you, and now I have to move onto other things.