Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finishing what you start makes teams more productive and predictable

lucasfcosta.com

Post reply on HN
Print view View original

11–20 of 165 posts

Re: Finishing what you start makes teams more productive and predictable

#11

Post by crnkofe »

I wish more people would read this. Both leads and devs. Finishing is the difficult part of software development. Conversely opening new projects/features/bugs is very easy. Opening many tracks in parallel slows down the entire team to a crawl to which the standard workaround is to simply work more hours o cut corners and take shortcuts thereby increasing tech debt as you go. Fight fire with fire.

I also find people are twisting definition of done to make it look as-if it's over. Something being coded usually isn't done. It still needs to be tested which is the labour intensive task. Something being tested isn't done, it must be shipped and released to production. Code in production still isn't done. It must work and be performant enough, might need more logs, might need more monitoring. Last but not least it must get into the hands of the users who give the final word. But even then it might not be completely finished.

Re: Finishing what you start makes teams more productive and predictable

#12

Post by kqr »

solatic wrote: post #7

Article relies on a non-sequitur assumption that you should work on an entire feature start-to-finish without interruption. What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority. This is what actually reduces batch sizes. Then deciding to prioritize the work to finish a feature instead of new work for a different feature becom…

I agree with the general idea, but I'm not sure putting development and product in an antagonistic relationship will improve things.

They're different professionals with different ideas of what's important. Someone in product is unlikely to understand the development cost of leaving something half-finished, because recognising it as a maintenance tar pit takes development expertise that can be hard to articulate (as expertise tends to be).

What's needed is close cooperation, not finger pointing.

Re: Finishing what you start makes teams more productive and predictable

#13

Post by roberttod »

I think those initial diagrams/explanations miss a key detail. The longest step in cooking burgers is the grilling step, in which the cook is just waiting for the burgers to cook, and won't speed up the process by giving attention to one burger instead of 2. The idea that 3 burgers would take 12 minutes while 1 takes 4 isn't realistic, even without all the batch processing math later in the article.

I still agree with the idea teams should do one thing at a time in general, but if you are going to do anything in parallel, it makes most sense to do other work when waiting for something to complete (as in the grilling step in this example)

Re: Finishing what you start makes teams more productive and predictable

#14

Post by kqr »

vaidhy wrote: post #9
kqr wrote: post #3

This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size. This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.) Why this matters is…

This assumes that tasks can be defined as small and large ahead of starting them which goes back to a similar mistake that you pointed out - our estimates need to be true and have high confidence. Estimates for tasks have high variance and some of them will turn out to be inordinately complex, though not clear at first. Second one is that it assumes all tasks are of same priority and the utility of all tasks are equa…

One of the neat things about the "always pre-empt the currently processing task" is that you don't need to know the size of any task! All you need to know is that it's variable, which you can find out from past data.

Re: Finishing what you start makes teams more productive and predictable

#15

Post by 8n4vidtmkvmk »

kqr wrote: post #10
vladgiverts wrote: post #6

Earlier quoted context omitted.

Speaking to the task size point, I’ve found (via leading a number of teams and training many more team leads) it’s possible to decompose any task into smaller tasks so that every task is within a small constant factor of each other. If it seems impossible for a given task, maybe because it’s particularly complex or has lots of unknowns, then no problem, simply create a “spike” task to research or prototype whatever y…

This has been true in my personal research too. When projects are sufficiently decomposed, a "ticket" about implementing part of a project is generally speaking within the same order of magnitude. However, this article is not talking about "tickets" but rather about the entire project. So that you may or may not be able to break the project down into roughly-constant chunks is irrelevant for the arguments of this art…

you have to be careful about pushing out an early MVP for "business value". my company tends to do this but the MVPs are so far from complete that I'm skeptical we're even getting good data out of it

Re: Finishing what you start makes teams more productive and predictable

#16

Post by 8n4vidtmkvmk »

klodolph wrote: post #5

Fact is, a team with five people working on five independent tasks may be able to proceed at high throughput, because of the cost of coordination when you assign multiple engineers to the same task. That is, if you have chef A making a burger, and chef B making a salad, and chef C making a cake, then they can all go at full speed because they're using different parts of the kitchen and don't need to coordinate with e…

i think we're talking about giving a single engineer multiple tasks.

Re: Finishing what you start makes teams more productive and predictable

#17

Post by jmathai »

In my experience on small teams that I've been on - a key motivator for people is shipping products and features. The sooner and more frequently you can do this the more positive reinforcement there is for the entire team - not to mention reduced risk of something never making it to the target users.

Teams that have figured out the optimal way to get product and features into the hands of users as quickly as possible are the happiest teams because it's evidence that they're working together efficiently to meet their shared goals.

Re: Finishing what you start makes teams more productive and predictable

#19

Post by kqr »

roberttod wrote: post #13

I think those initial diagrams/explanations miss a key detail. The longest step in cooking burgers is the grilling step, in which the cook is just waiting for the burgers to cook, and won't speed up the process by giving attention to one burger instead of 2. The idea that 3 burgers would take 12 minutes while 1 takes 4 isn't realistic, even without all the batch processing math later in the article. I still agree wit…

Now we're really taking the analogy apart until it's no longer reasonable, but I'll continue:

Sometimes it makes sense to stand around waiting for the burger to cook. Maybe all you have to do are low-value burgers and it's nice to maintain an idle chef for any high-priority burger tasks that come in.

Or there are important but non-burger tasks that need to be done but are easily deprioritised in favour of burgers.

Re: Finishing what you start makes teams more productive and predictable

#20

Post by muzani »

roberttod wrote: post #13

I think those initial diagrams/explanations miss a key detail. The longest step in cooking burgers is the grilling step, in which the cook is just waiting for the burgers to cook, and won't speed up the process by giving attention to one burger instead of 2. The idea that 3 burgers would take 12 minutes while 1 takes 4 isn't realistic, even without all the batch processing math later in the article. I still agree wit…

There's a book, Everything In Its Place, Dan Charnas, which does a good analysis of the analogies of cooking and productivity in the office.

Basically it recommends doing the "process" tasks first, the ones that the rest rely on. In this case, it would be grilling burgers. In the office, it might be something like assigning tasks or approving PRs.

Charnas recommends that planning starts by "first things first" as opposed to say, the Tim Ferriss, Brian Tracy, or Eisenhower methodology of most important things first. And often the first thing is to figure out which things come first.

And yeah, the book also recommends finishing where possible. A dish 90% done might as well be 0% done, but it occupies mental space while it's not done.

Post reply on HN