The elephant in the room here — and this is no judgement — is that the contractor isn't worrying about creating more technical debt or something that will fall down in a year's time. It's YAGNI taken to an extreme. As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward. I've also been at - more than once - given managerial control of a large codebase driven exclusively by the need to deliver deliver deliver and had to explain to the company why development has become so much slower since they started.
> As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward.
It's one thing to have the domain expertise to accurately anticipate future asks and preemptively prepare for them. But I've seen very few cases of that, compared to projects that were design pattern lasagna. Layer upon layer of abstraction to solve imaginary problems that were never real nor will ever become real. And all those abstractions cost the same as those which actually solve problems.
My approach is always to solve the problems you actually have, and no more. This includes abstractions for unit tests; that's an actual problem. (You are putting all those external dependencies behind interfaces for mocking, right?)
