I should have qualified my statements with "probably" and "the majority of the time". There is more nuance to this than I considered when I wrote my reply.
However, that being said ...
> I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either.
Cutting corners saves a boatload of time if you're only ever testing the Happy Path. HP-only testing, alone, roughly halves the time to ship a product, once you realise that no dependency-injection would be required so you just hard-code the dependencies in the class hierarchy or data structures.
More time can be saved by sticking to a single platform ("Does this Go program work on Windows too?" "Meh. Who cares?"), yanking in every library there is ("Why does this run so slow?" "Because developing for Electron is faster than making a native app").
The point is, quality takes time. It takes longer to prepare a great meal from fresh ingredients than it does to simply assemble a picnic from nothing but KFC, McDonalds and Krispy Kreem. It takes longer to build a house from concrete and block than from wood and siding.
> Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code.
If the startup is pivoting, then they're likely throwing away most of what they built anyway. That's the whole point of the pivot - you switch from producing a product for solving $FOO to a product for solving $BAR.
If you aren't throwing away most of what you have written, you aren't pivoting.
However, that being said ...
> I think this is where I disagree - cutting corners is really not faster. Especially now a days with the tech and libraries we have available, you don't have to overthink or overbuild either.
Cutting corners saves a boatload of time if you're only ever testing the Happy Path. HP-only testing, alone, roughly halves the time to ship a product, once you realise that no dependency-injection would be required so you just hard-code the dependencies in the class hierarchy or data structures.
More time can be saved by sticking to a single platform ("Does this Go program work on Windows too?" "Meh. Who cares?"), yanking in every library there is ("Why does this run so slow?" "Because developing for Electron is faster than making a native app").
The point is, quality takes time. It takes longer to prepare a great meal from fresh ingredients than it does to simply assemble a picnic from nothing but KFC, McDonalds and Krispy Kreem. It takes longer to build a house from concrete and block than from wood and siding.
> Cutting corners saves no time, and then the startup needs to pivot and can't easily due to the ham strung code.
If the startup is pivoting, then they're likely throwing away most of what they built anyway. That's the whole point of the pivot - you switch from producing a product for solving $FOO to a product for solving $BAR.
If you aren't throwing away most of what you have written, you aren't pivoting.