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

Re:Speed matters: Why working quickly is more important than... by illuminati1911 on Monday August 05, 2019 @03:18AM (#20611980)

Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start.

At least according to my experience and everyone I know in the industry.

[ Parent | on HN ]

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

But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks.

I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.

[ Parent | on HN ]

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

What if there's no automated testing worth a damn, and the penalty for a bug is very high? Been there, done that, and I have to say, you don't ever want to stay there!

[ Parent | on HN ]

Re:Speed matters: Why working quickly is more important than... by rooam-dev on Monday August 05, 2019 @06:48AM (#20612961)

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.

[ Parent | on HN ]

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 ]

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

If you work on legacy code you can be sure that your code will be used for years if not decades.

[ Parent | on HN ]

Re:Speed matters: Why working quickly is more important than... by Nyandalized on Monday August 05, 2019 @08:58AM (#20613792)

Legacy code often ends up as such, because it was immediately available and immediately utilized. It worked then, and piled on functionality.

You don't see good looking legacy, because it didn't survive.

[ Parent | on HN ]