Speed matters: Why working quickly is more important than it seems (2015)

Re:Speed matters: Why working quickly is more important than... by skohan on Monday August 05, 2019 @06:52AM (#20612988)

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.

[ Parent | on HN ]

Re:Speed matters: Why working quickly is more important than... by stcredzero on Monday August 05, 2019 @01:22PM (#20616044)

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.

[ Parent | on HN ]

Re:Speed matters: Why working quickly is more important than... by sejtnjir on Tuesday August 06, 2019 @07:47AM (#20624274)

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

[ Parent | on HN ]