[lumost]

From a practical perspective, most companies large enough to support PEs as described here, are going to have misaligned hacks that made sense once upon a time but are no longer sensible.

A big part of a PEs job is to keep the train moving despite nonsensical design decisions, organizational politics/empires, and legacy code bases/use cases that no one wants to touch. A good PE will help incrementally resolve/improve the above situations.

[bob1029]

> A good PE will help incrementally resolve/improve the above situations.

100% agree. What I posted above is an idealistic perspective in which you get to greenfield an application from zero. Most real world situations involve some degree of legacy domain implementations which must be bridged into the future.

Being able to rebuild the ship from the inside while it is sailing to the new world is an incredibly valuable skill set. Many developers get frustrated and demand a total rewrite (I used to do this). It would be really hard to make forward progress if you start off with a new ship in Spain every time you encountered the slightest bit of friction.

[Diggsey]

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.