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

121–130 of 165 posts

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

#121

Post by kqr »

wizofaus wrote: post #80
kqr wrote: post #2

This is a fun experiment along the same lines: https://m.youtube.com/watch?v=Dr67i5SdXiM The result surprised me even though I know intellectually I should have expected it.

That's because it chooses a bad example of an activity for which production-line methods make sense. Pick an activity (that you need to repeat many times) where each step requires quite different tools and skills that are difficult to master, and breaking it up into tasks for individuals who specialize in said tools/skills is almost certainly going to get you better throughput. Even in the letter-stuffing example, if…

One piece flow doesn't mean the same person does everything. It could mean that multiple people do their specialty, but instead of working at their own pace with storage between them, one passes their work product directly into the hands of the next when the next one is free.

I have done the experiment with the envelopes that way too with similar results.

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

#122

Post by FearNotDaniel »

muzani wrote: post #20
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 opp…

That's a great read, although I remember reading it published under the title "Work Clean". A cursory glance at Amazon.co.uk looks like the two titles have identical text however the Kindle edition of "Work Clean" is half the price of the one re-issued as "Everything In Its Place", for anyone else interested...

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

#123

Post by fendy3002 »

boffinism wrote: post #43

I once worked in a VERY chaotic startup with near-constant pivots and priority shifts. In each case, at the time, the change in direction could be justified... but morale was chronically low, particularly among software engineers. I spoke to one who, after a year, mournfully revealed that none of the code he had written had ever shipped. He, and most of his colleagues, burnt out and dropped out pretty fast.

One year? Try two and a half years without anything shipped. It's even worse that no project is being tested until two years mark.

It is really demoralizing and shows how inefficient and unorganized the company at running IT-related projects.

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

#124

Post by yakubin »

BurningFrog wrote: post #107
yakubin wrote: post #50

Earlier quoted context omitted.

> Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do like having this kind of daily routine so mileage may vary obviously. Same here. I used to be in a team with daily stand-ups, reporting to the manager what work I did the day before, and they killed my will to work, consequently causing me to work ~3 times slower, which presumably is the opposite…

The standups I've been in are about reporting to the rest of the team what you're doing. This way, everyone has a clue what's going on, and can also chime in with advice and questions.

I'm not against stand-ups per se, just against daily stand-ups. Currently I'm in a team which does three a week. That's at least tolerable, but if it was up to me, I'd opt for once a week. Daily made me feel that I had no agency over my work, that everything to the tiniest detail needed to be negotiated with someone, most often the manager. Less agency means lower engagement in work. At least for me. I do know that there is plenty of other people who are different.

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

#125

Post by morelisp »

rekrsiv wrote: post #116
morelisp wrote: post #113

Earlier quoted context omitted.

But it doesn’t need to be possible all the time, just often enough to set bounds acceptable to the rest of the organization. And how are you going to know unless you’ve already done it a hundred times, and/or try?

The problem with acceptable bounds is when they're applied uniformly to all your code monkeys without adjusting for experience and mental state at any point in time and we can't sample those values in real-time. Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time. Predicting the future of a high…

What pop nonsense. An unpredictable software engineering team is itself a barrier limiting the creativity of the product team (and vice versa). If you don't want to be treated a crank to turn, you also need to bring some self-reflection, compromise, and willingness to communicate to the table.

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

#126

Post by Nemi »

Though I agree with the premise of this article, I simply can’t get past his burger example. Let me explain.

Multi-tasking has exponentially greater impact on performance the greater the complexity of the task. Most people just don’t find themselves doing these kinds of complex tasks on a daily basis. This is why coming up with a simple example that lay-people can understand is so hard. Simple examples don’t pass their sniff-test. It is obvious to anyone thinking about it that I can make two burgers simultaneously and it only adds a fraction to the overall time. This is because the complexity of the task is extremely simple. In reality it would add seconds, not minutes.

However, once you ramp up the complexity of the task this penalty does approach 1 to 1, or greater. It is obvious to anyone that having to do a heart transplant while also doing your taxes at the same time would require longer than either task individually. An example like that is also easily dismissed because it is so far-fetched.

I find that to really impress on people the penalty involved requires an example that is personal to them. If you can find some complex tasks that they do even rarely and have them envision doing them simultaneously, then they are more likely to buy into the idea. Let’s be honest, most people don’t find themselves in this situation like programmers do because of the deep thinking that programming requires, but if you search hard enough you can usually come up with some personal examples for people. If the person you are trying to impress is important enough in your life (spouse, boss, etc), then it is worth the effort to find some individual examples.

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

#127

Post by shagie »

barking_biscuit wrote: post #92
jraph wrote: post #23

Earlier quoted context omitted.

Releasing is great. Unused work is quite sad. A big condition for motivation though is if people are not pressured to rush features. Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too. Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a…

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.

Shipping an 80% solution is ok... it leaves a bad taste, but its "ok".

The problem becomes more-so when the next 80% solution is shipped on top of the previous 80% solution. And that just gets demoralizing after a time when one looks at the stack of 80% solutions on top of 80% solutions that needs to get fixed up (but "we don't have time to do that").

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

#128

Post by morelisp »

shagie wrote: post #127
barking_biscuit wrote: post #92

Earlier quoted context omitted.

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.

Shipping an 80% solution is ok... it leaves a bad taste, but its "ok". The problem becomes more-so when the next 80% solution is shipped on top of the previous 80% solution. And that just gets demoralizing after a time when one looks at the stack of 80% solutions on top of 80% solutions that needs to get fixed up (but "we don't have time to do that").

One thing I tell our developers (and POs) is that we can only tolerate 80% solutions so long as they also produce 120% solutions (or give us additional time/scope for them) at approximately the same rate.

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

#129

Post by rsanek »

Nemi wrote: post #126

Though I agree with the premise of this article, I simply can’t get past his burger example. Let me explain. Multi-tasking has exponentially greater impact on performance the greater the complexity of the task. Most people just don’t find themselves doing these kinds of complex tasks on a daily basis. This is why coming up with a simple example that lay-people can understand is so hard. Simple examples don’t pass the…

I found the example used in an anti-multitasking book I read to be both simple and compelling. The idea was to write all letters from a to z and all numbers from 0 to 25. Compare the total time between writing the alphabet first and then the numbers (abcd...; 1234...), vs. mixing the two (that is, a1b2c3d4...). The separate approach wins by a large margin, and is accessible to anyone to try themselves.
Post reply on HN