[taude]

I think it depends on the problem set and where one works, etc. There's a lot of use cases where getting it over the wall is perfectly acceptable and what the business needs. I can cite numerous incidents where a lot of code was design, written, and then out of circulation less than a couple years later. I also know of instances where some crappy code stuck and is in use 14 years later. The hard part is knowing which is what, and some of this can be alleviated by a decent modular design and taking on tech debt to refactoring/swapping out certain implementations for more robust implementations at a future date. It's hard to balance delivery time frames with robust/clean code, especially when so many opinions drive the later. Hopefully you get to work in a place that favors the slower, better planned approach approach.

[pooktrain]

> and some of this can be alleviated by a decent modular design and taking on tech debt to refactoring/swapping out certain implementations for more robust implementations at a future date

Absolutely, but even that idea of "modular design" would be something that needed to be discussed by the team - but this article would label this a "fixation". This distinction really isn't helpful. What IS helpful is knowing how much time to spend on such a debate, and when to set that stuff aside in service of moving on with the work.

[raiflip]

> where some crappy code stuck and is in use 14 years later

I think this boils down to a roll of the dice. Its possible that some code is simple enough, or some engineer is smart enough, that tests are not really needed, but given the choice to not unit test would be made early, and its very hard to know the complexity of the solution at the beginning, you're really just rolling the dice with regards to whether it would work out. Sometimes you get a huge payout by delivering good code fast, but sometimes it can really blow up in your face with lots of prod errors.

Personally, I'd rather smooth out that large payout vs large explosion curve by just writing tests. If we could have pushed out the code faster, that is a loss, but if the code would have had many errors, thats a gain. So probability distribution with regards to payoffs is smoothed out.