> You can't properly see how the software evolves in 2 years
I'd counter that this is subjective based on experience.
If I've built a similar system before, it's in the same domain, and the customer/userbase has a similar profile, then it makes sense that an engineer that's "been there, done that" can foresee the needs of the system, domain, and customer and can more accurately extrapolate how the system will need to evolve.
I assume that this is one of the reasons teams hire for both technical and domain experience.
As an example, I spent more than a decade building regulated document management systems and it's clear to me what needs to be done to scale the system to support millions of documents. Is it premature optimization or over-engineering if I join a team that's building a new document management system and I design it to scale from day 1?
Similarly, if you're building a product that interacts with calendars, perhaps you start with only supporting GCal, but you can already extrapolate that the market has 2 other major calendar providers to account for: Outlook 365 and Apple iCal. Wouldn't it make sense to write an interface here knowing that a year down the line, you'll add support for O365 and then another year after, add support for Apple?
To an engineer or product manager new to the space, any extra effort looks like "over-engineering". For someone that's built similar systems for over a decade, some decisions seem inevitable because the usage patterns of such systems are not that different and will eventually converge so one might as well start with that endpoint.
I suspect that some decisions made in the development of Threads or BlueSky might seem like "over-engineering". But those teams are not working in a vacuum; they already have a sense of how such systems will grow over time based on experience.
Thus I would make the case that the cost of perceived "over-engineering" is also going to differ. For someone doing it for the first time, that perceived cost is higher than for someone doing it the 2nd or 3rd time.
My take is that what is "over-engineered" has a subjective aspect based on the experience level of the parties involved.
> > You can't properly see how the software evolves in 2 years
> I'd counter that this is subjective based on experience.
> If I've built a similar system before, it's in the same domain, and the customer/userbase has a similar profile, then it makes sense that an engineer that's "been there, done that" can foresee the needs of the system, domain, and customer and can more accurately extrapolate how the system will need to evolve.
Don't just ignore the first part of their comment:
> > The problem is people stay at a job for 2 years.
You can't "been there, done that" if you haven't "been there" in the first place.
It doesn't really matter if the domain is the same.
If you're building a regulated document management system for life sciences, the big picture aspects of what it has to do, how it has to scale, and how it has to be packaged (process, testing, documentation) doesn't have much variance.
> that an engineering that's "been there, done that" can foresee the needs ...
Agreed.
That said, where I've encountered the most issues have been when engineers who are relatively new hires *believe* they've "been there, done that", and haven't yet internalized the different nuances of the situation vs their prior experience. This sets up a dangerous scenario where they have enough experience to be quite believable, but unfortunately may be missing the fact that their experience isn't as applicable as they believe.
If I've built a similar system before, it's in the same domain, and the customer/userbase has a similar profile, then it makes sense that an engineer that's "been there, done that" can foresee the needs of the system, domain, and customer and can more accurately extrapolate how the system will need to evolve.
I assume that this is one of the reasons teams hire for both technical and domain experience.
As an example, I spent more than a decade building regulated document management systems and it's clear to me what needs to be done to scale the system to support millions of documents. Is it premature optimization or over-engineering if I join a team that's building a new document management system and I design it to scale from day 1?
Similarly, if you're building a product that interacts with calendars, perhaps you start with only supporting GCal, but you can already extrapolate that the market has 2 other major calendar providers to account for: Outlook 365 and Apple iCal. Wouldn't it make sense to write an interface here knowing that a year down the line, you'll add support for O365 and then another year after, add support for Apple?
To an engineer or product manager new to the space, any extra effort looks like "over-engineering". For someone that's built similar systems for over a decade, some decisions seem inevitable because the usage patterns of such systems are not that different and will eventually converge so one might as well start with that endpoint.
I suspect that some decisions made in the development of Threads or BlueSky might seem like "over-engineering". But those teams are not working in a vacuum; they already have a sense of how such systems will grow over time based on experience.
Thus I would make the case that the cost of perceived "over-engineering" is also going to differ. For someone doing it for the first time, that perceived cost is higher than for someone doing it the 2nd or 3rd time.
My take is that what is "over-engineered" has a subjective aspect based on the experience level of the parties involved.