[davidmurdoch]

Incorrect and not even close.

Greenfield is easy because nothing matters yet.

No legacy data. No backwards compatibility. No users depending on uptime. If the architecture is wrong you just rewrite it, rename a few services, and move on.

Maintaining and expanding a real system means every change has consequences. You’re migrating live data, preserving behavior people rely on, and evolving the architecture while the plane is already in the air.

0→1 lets you be bold because you can break things. 1→10M is harder because you can’t.

(I'm just kidding, your dismissal just needed a dismissal to make things balanced again)

[reactordev]

Yeah, you just described why doing green right is hard. It has to account for future state. It needs to be accommodating to change. I know we all had that experience where we come in and some slop is running in production and we are tasked to rewrite it. This isn’t that. Those suck. They deserve their own bin of humiliation. The great designs allow future development to add to the ecosystem. The argument “You never stay so you never built anything that lasts” is untrue when you build a platform that is extensible and has been running that way for 30 years. I haven’t been needed in 29.

But yes, as everything in life, YMMV and all jobs are a double edged sword. Some greenfield is shit because shitty decisions were made. Some enterprise is shit because some shitty decisions were made. In either case, whether it’s a new project or fixing an old one, take your time and not make shitty decisions.

(Spider-Man Point Meme)

(I don’t make products, I create legacies, in C++)