[titzer]

> The top two sources of failure in software development projects are failing to discover what is actually needed and failure to eliminate chaos in the software before delivering it to the customer.

The first one is called requirements gathering (the method, requirements engineering). I was wondering how far I was going to have to read to find someone mentioning that.

It can be as simple as writing down a list of things the software has to do. It could be one afternoon brainstorming meeting, to start. But we don't even bother. Why? Because this discipline is not engineering, not science, not manufacturing. One my darker days, I think we are just playing in the mud.

I am grateful to work on virtual machines and compilers. They at least have functional requirements--an input specification--and a well-specified target machine. The rest in the middle is a fun design exercise, but there is a crucible at the end of the day. If you can't run the programs without bugs, you have failed. That makes it easy to put functional correctness first and performance second, as it should be. We need to find more ways of translating problems into requirements in order to reduce black art to science to practice.

[blacktriangle]

I agree it's a bit like playing in the mud, but the more I work the more I suspect that's just accepting reality.

Requirements gathering works wonderfully for internal projects with a fixed set of stakeholders and a well defined problem with measurable outcomes. Product development is a whole different world whose outcome is the much more vague "generate profit for the developers". Particularly in the realm of B2B software.

You need to find some local minimum that will meet the needs of thousands of organizations in order for development to be worthwhile.

You need to get many busy people who don't know you to actually talk to you.

You need to talk to multiple different stakeholders within the organization.

And even after you group all your stakeholders into some kind of user personas, you still haven't accounted for what the larger organizational behavior will be, as B2B products generally require large-scale buy-in.

And at the end of the day, no matter what people say they will do, the true test is when a company actually opens their coffers and pays your invoice.

We've arrived down here in the mud through years of experience of doing requirements gathering, building to a spec, and then finding out that we built the wrong thing and nobody will pay us for all our hard work.

Sometimes you really do have to build it to see if they will come. And the more formalized (ie expensive) you make the requirements engineering process, the more compelling the iterate and start getting paying customers asap plan becomes.

[djmips]

>"That makes it easy to put functional correctness first and performance second, as it should be."

That only works when performance isn't a core deliverable. In my area, that have to be co-developed as it is too expensive to build merely functional and make it fast later.

[Jtsummers]

As I had to convince a former colleague, fast but wrong is useless. I can make a very high performance program if correctness is irrelevant. Correctness is the requirement (at least from my professional work), and performance is necessarily secondary. That doesn't remove it as a requirement, but if I'm giving wrong results quickly then planes aren't flying (worst case, they're burning up on the ground and everyone is dead). Performance is obviously important because I've mostly worked on real-time systems. But I can take a correct program and make it fast much more easily than taking a fast but incorrect program and make it correct.

I guess if your work has no consequences correctness can be discarded or rendered a secondary criteria for your programs.

[titzer]

Oh, believe me, performance of a Wasm engine is a core deliverable.