Hacker News Reader

Comment by thedg | Hacker News Reader

> At first glance it looks like I get less done, but when you account for the fact that nobody has to clean up after me or shoehorn a work around for an edge case in I become one of the most efficient.

That's so awesome.

The Jam dev team recently shipped a major refactor of all the state handling in the app a few weeks ahead of schedule and that's because the team spent so much time upfront documenting and planning the changes. Thanks to Tony Stuck for showing us how important doing upfront planning is on the Jam engineering team!

View on HN

> The Jam dev team recently shipped a major refactor of all the state handling in the app a few weeks ahead of schedule

To me that doesn't sound like a thing to be proud of.

1. You approved a plan to have a refactor that lasts several weeks. Even for big companies that's usually an anti-pattern. It even contradicts your own advice of "make things better as you go".

2. You tremendously overestimated the required effort (i.e. absolutely failed at planning)

3. You got lucky this time and two wrongs made a right.

Also, your example suffers from survivorship bias. Of course everybody has examples where planning paid off. But there are also plenty of examples where planning was a waste of time, or where people were following outdated plan for the sake of following the plan. "More planning" is a bad advice. A good advice helps distinguish areas that benefit from "more planning" from areas that will suffer from it. But that is hard and nuanced.

This comment isn't anything to be proud of either. Go piss in someone else's cheerios.

Sounds more like engineers managed to communicate why it was worth doing a refactor to the stakeholders, made a rough estimate, and then through a solid round of planning managed to find out how to reign it in a bit. Sounds like something to be proud of to me.

> [It is a problem that y]ou approved a plan to have a refactor that lasts several weeks.

I've been working at an Agile(TM) "prefer communication to processes" shop for a while now.

One thing that they absolutely do _not_ understand is that sometimes the smallest unit of work cannot and can never fit into a one (or even two) week Sprint.

If someone comes and says "This project will take a long time.", yeah, sure, sit down and have them explain why. Do _not_ shoot them down as a matter of course because "Well, nothing should take more than a week, and _definitely_ never than two." and tell them "Go mutilate your plan so that you have a Real Deliverable every five working days.".

> You tremendously overestimated the required effort...

a) Neither of us know how long the entire project ran, so "A few weeks" could be a small overestimate, and evidence that a sane amount of cushion was baked into the planning.

b) It's way, way, way better to overestimate a fair bit and come in under that estimate than it is to underestimate and _require_ either rescheduling a whole bunch of shit, or mutilating a solid plan in order to shove it out in the original timeframe.

> Go mutilate your plan so that you have a Real Deliverable every five working days

If we're talking about web development - yeah, pretty much. IME, most projects where team lead was not willing to "mutilate" were a disaster.

> Neither of us know how long the entire project ran, so "A few weeks" could be a small overestimate

Are you saying changing state handling (whatever this means) in a young startup could take several months? If that's the case, they definitely should not be teaching how to move fast.

> ...most projects where team lead was not willing to "mutilate" were a disaster.

It seems like you agree that my core statement ("sometimes the smallest unit of work cannot and can never fit into a one (or even two) week Sprint") is correct, but are unwilling to explicitly say so.

> Are you saying changing state handling...

I'm saying that neither you nor I have the details required to understand the minimum time required for the project.

You've said yourself that you have experience with tasks that have justifiably run longer than a work-week. So, it's clear that -given more information about the task- you could be convinced that the time estimate is a reasonable estimate of the time required.

Reply on news.ycombinator.com