"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live" (link)
And from my experience software products are annoyingly long lived while needing to be continuously adapted to ever changing circumstances in order to remain valuable.
The type of development velocity you seem to be interested in is referred by J.B. Rainsberger as "the scam":
The cost of the first few features is actually quite a bit higher than it is doing it the "not so careful way" ... eventually you reach the point where the cost of getting out of the blocks quickly and not worrying about the design is about the same as the cost of being careful from the beginning ... and after this being careful is nothing but profit.
He acknowledges that "the scam" is initially incredibly seductive - and the approach that you describe in the article has that same seductive appeal. The velocity of that approach moves quickly to the point where the cost of continuing is higher than the cost of starting again.
So the value of that approach can only be realized if the product is decommissioned before the "breakeven point" (my guess less than two years, possibly less, depending on project type). The only other option is to make the product "somebody else's problem" before that breakeven point is reached (which obviously isn't doing them any favours).
Again, thanks a lot for your detailed answer but I am afraid we will never agree.
It's like a left brain speaking to a right brain:
Both approaches are valuable and choosing one over the other really depends on the project you are working on.
My mindset:
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live" (link)
And from my experience software products are annoyingly long lived while needing to be continuously adapted to ever changing circumstances in order to remain valuable.
The type of development velocity you seem to be interested in is referred by J.B. Rainsberger as "the scam":
He acknowledges that "the scam" is initially incredibly seductive - and the approach that you describe in the article has that same seductive appeal. The velocity of that approach moves quickly to the point where the cost of continuing is higher than the cost of starting again.
So the value of that approach can only be realized if the product is decommissioned before the "breakeven point" (my guess less than two years, possibly less, depending on project type). The only other option is to make the product "somebody else's problem" before that breakeven point is reached (which obviously isn't doing them any favours).
I'm only interested in going faster than "so called fast" - going well for long enough so that I'll beat fast all the time.