[rooam-dev]

The question is, if the project you worked would be a mess from the beginning, would it allow your company to test and scrap features fast?

Yes, it's possible, but at what cost? E.g. long hours, unhappy devs, implementation taking too long.

[skohan]

The point is there's a balance. I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.

It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always, but in my experience it can be much more productive overall.

[stcredzero]

I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.

The point of code quality is to enable the company to change its mind or add new features. Over-perfectionism that gets in the way of this is going too far. At one company I worked for, the policy was not 100% strict DRY. Instead, we waited for 3 uses of the same idiom before we put it in the library. This prevented the collection of too many trivial methods, while still giving the benefits of DRY.

[sejtnjir]

Smart devs know they probably get the abstractions wrong until the third iteration. This sounds like a sane policy.