| Unfortunately what you're describing never actually occurs in practice, unless you're simply rebuilding an existing piece of software, which has only technical improvements (ie. better performance, fewer bugs, etc). The cases where you are starting from zero are also the cases where you don't understand the problem domain to a sufficient degree. You can try to get clients involved earlier, but that is very dangerous: - It's hard to get a sufficient diversity of early users. - Clients are incapable of prioritising what's important. Everything feature they think of (even the things they won't actually use) will be essential to them if you ask. - The actually essential features will be so obvious to them that they won't even think of mentioning them. - They don't understand abstractions: any concept you try to define with their help will become amorphous and therefore useless. - Engineering is fundamentally subtractive: with zero code a product could eventually do anything. As you add code, you are restricting what it can do so that the results are the "useful" ones. For example. when you create a "user" table with an "email" property, you are restricting users to have one email address. You cannot make progress without these restrictions, but if you actually spell out those restrictions, you'll get massive pushback. This is why so many engineers like building things for other engineers - because they can be their own client. It's also why it's impossible in most cases to go from zero to a well-architected product in one go. |