Very much depends on what you are working on. What SaaS is ever stopped being developed and doesn’t need ownership after 2-3 years? Products with embedded software might ship in 2-3 years but many still need bug fixes and new features long after that so therefore needs ownership.

If it’s a saas then original mvp will take anywhere from 6mo to 2y then it either dies or scales in which case it’ll be nearly rebuilt again with a much larger team this time. Therefore you will not learn anything on year 4 that you didn’t already learn in year 3

As a data point, I've worked at several companies powered by software they'd begun writing ~8–20 years earlier. No rewrites.

These projects were the cornerstones of businesses sized from a couple dozen to a few hundred employees.

Is this an honest question or one of those HN social status signalling things where we all feign unfamiliarity with what software development looks like outside of the YC bubble? Not snark, seeking clarification.

My understanding is that they meant actual individual projects within large companies never take this long. So "projects" as in "features" that ICs work on. I agree with that point, I hardly ever get to go back an evaluate the decisions I made a year ago. Ownership changes happen all the time, plus refactors, stack upgrades, other code changes... No one I know gets to work on a single self-contained feature/area for 6-7 years straight.

If you're working in a company that large then presumably you have architects and leads who are making broader decisions that you can see the effects of.

the point about being around for longer to see the effects of your mistakes assumes you're not a cog in the wheel.

I don't think this article limits the definition of architecture exclusively to very broad systems, like designing a new graph DB service. Architecture choices happen at all levels, and true systems architects are seldom involved in that.

> the point about being around for longer to see the effects of your mistakes assumes you're not a cog in the wheel.

Ideally—yes. In practice, decisions that should take QARs into account but don't are made by almost any IC level. I have seen systems designed by interns. You could say it's a company culture problem, and I would partially agree. On the other hand, tech companies have a tendency to lean into empowering ICs and so what ends up happening is that inexperienced engineers design systems that are only reviewed by overworked (and maybe not particularly experienced and/or motivated) senior ICs.

I definitely know more about non-YC than "YC bubble" and having talked to a bunch of YC founders i'm pretty sure there isn't a specific to YC way of building software - lots of different companies trying totally different things

Your question gets a SaaSy reply.

Webshit has a famously short half life, but there are many companies that want real products with real support and development over many years.