I agree, it is "programming" vs "software engineering".
You are looking at the problem as a programmer, and making reasonable assumptions about how to solve the problem using objects and graphs and interfaces and models. If we had a better model, our project will go faster and be better.
I am looking at it as an engineer, and seeing what actually happens in real life when real humans build real code. If we had working code for simple problem A, then when we get to more complex problem B, our developers will have more experience, better morale, and better support from management who have happy customers.
Your response is actually very surprising. I'm looking at the problem as a software engineer, who has to make architectural decisions about the applications I'm building. You're looking at it like a programmer. YAGNI is very much not an "engineering" response, it's a "programming" response. Engineering is all about careful, methodical design and architecture and planning for the future maintenance of the product. YAGNI is pretty much the antithesis of this.
I'm curious what kind of software you work on. Most of the software I do is applications / frameworks development. Planning ahead is very important when developing the architecture of an application, and is doubly-so when doing any kind of API design (both when developing frameworks and when developing reusable components inside of applications). You certainly don't need to implement everything up-front, but you do have to understand the future requirements and design appropriately. Failure to do so leads to blowing out time / budget estimates later when you realize your code isn't maintainable anymore and all the "quick" implementations people did to avoid having to make architectural decisions are now so fragile and dependent upon assumptions the implementor probably didn't even realize they were making that you can't change anything without having large ripple effects.
I am the lead architect of a public facing data platform for a fortune 500 company. I influence over 60 engineers through my team of architects, and indirectly influence countless other teams deploying to our platform. My background is start-ups.
We do not suffer the failure modes you describe in your second paragraph.
I take it "data platform" means server-side work? I was guessing that was your line of work. In my experience, server-side programming and native client software (applications, frameworks, or systems) are pretty radically different in a lot of non-obvious ways. I think this might be one of them.
After reading this thread (and others from lowbloodsugar) I would say that I disagree with you here and what I do is similar to what you do. Specifically, I think that architectural choices are only important in a planning phase when they affect how people will collaborate. Architectural choices such as data or system design within that collaborative framework are irrelevant to anything you don't have to build right away.
You are looking at the problem as a programmer, and making reasonable assumptions about how to solve the problem using objects and graphs and interfaces and models. If we had a better model, our project will go faster and be better.
I am looking at it as an engineer, and seeing what actually happens in real life when real humans build real code. If we had working code for simple problem A, then when we get to more complex problem B, our developers will have more experience, better morale, and better support from management who have happy customers.