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

81–90 of 165 posts

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

#81

Post by solatic »

doix wrote: post #40
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…

> What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority. I would say this is pretty standard, and personally I really hate it. I think it works well if you want to prioritize hitting a date above all else, especially with a junior team or in a "low trust" environment (cheap off-shore team). But for other metrics, I don't think…

I'm not arguing that Product should sit high and mighty and refuse to listen to Development. Great ideas can come from everywhere, including Development, of course. But understanding what ought to be built, at least for functional requirements, is fundamentally Product's job and their decision.

What great teams do is that they have a Product guy sit on the same team as Developer guy(s), precisely to avoid the malaise you describe.

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

#82

Post by hnbad »

hnbad wrote: post #79

"It's effortless to switch from working on one burger to another" This is why software engineers should be banned from writing about anything outside their very narrow domain (and I say that as a software person). There's context switching when working on different features, sure. But there's context switching when working on different parts of the burger, too. Slicing two buns is faster than slicing one bun, then co…

As others have pointed out, the analogy doesn't even work for what it is trying to do. Tasks are heterogeneous (as are the features themeselves) and some steps involve passive wait time (e.g. waiting for CI, QA or reviews, or waiting for the grill to do its thing to the patties). Religiously linearizing the process by isolating each feature may actually often prolong the overall time in these cases.

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

#83

Post by peoplefromibiza »

baby wrote: post #47
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 think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

I believe this also depends on who you ask

For me deadlines are simply "someone wants this and this delivered @" I work on it a couple of days and then I tell that someone if it's reasonable and if it's not reasonable, what they are gonna get instead.

Most of the times deadlines are way off the mark and it also happens that they take 1/3 of the planned time, in that case instead of over engineering, I simply rest or study something new.

Over engineering is a curse only if one can't stop doing it and needs an external stimuli to mark the feature as "done".

Otherwise I believe most programmers know when their work is finished and can be shipped.

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

#84

Post by hnbad »

openfuture wrote: post #53
rdoherty wrote: post #4

If you liked this post, the book Making Work Visible is a great expansion on these topics. Making Work Visible: Exposing Time Theft to Optimize Work & Flow https://www.amazon.com/dp/B09L3B9YK1/ref=cm_sw_r_apan_AX66TB...

"Time theft"?! Oof I sincerely hope he got that the right way around rather than predictably inverting it.

Based on the summary I think the author just uses an unfortunately overloaded term. The "time thieves" aren't supposed to be the employees but inefficient processes slowing them down.

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

#85

Post by rightbyte »

Archelaos wrote: post #55
coderintherye wrote: post #22

This is why when leading an engineering org I narrowed down to one metric: Committed to Completed Ratio It encourages completing things and only committing to what you can complete. It's legible, easy to understand by engineering, product, and management, pointless to game, and positively reinforces completion. It's quite difficult to accurately predict when a complete feature will ship, let alone a whole product. Bu…

But how do you encourage people for difficult tasks? It is easy to commit myself to correct a particular spelling in a lable by tomorrow. But to fix the indeterministic bug that crashes our top client's server every now and then?

It is like metric driven development is a bad idea ...

As soon as any "oh this wont be used for your yearly review" metrics are made up. You need to drop everything and play by the metrics.

I guess a commited to completed ratio encourages padding out the estimate on easy tickets and punnishes doing hard tickets.

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

#86

Post by ChrisMarshallNY »

A key philosophy of mine, is "Success begets success."

I'll set goals small, so success and completion are guaranteed, then raise the bar a bit, on the next one, and so on.

Soon, success and completion become habit, for the team, and the results are amazing. I end up with a team that isn't arrogant, but highly confident, and quite efficient.

"Succeeding" also requires things like careful attention to detail, good testing (and fixing), documentation, and other "boring" stuff. Once that becomes habit, it's just "background noise."

It just takes time, and that is something that seems to be at a premium, these days.

But regular success just feels good. I recommend the practice.

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

#88

Post by baby »

valenterry wrote: post #49
baby wrote: post #47

Earlier quoted context omitted.

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

I think for junior developers that might be true. Does the name connect? :)

no I'm not junior

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

#89

Post by rubyist5eva »

miga wrote: post #60

When one uses manufacturing job (burgers) as metaphor for software development, then you see that the guru thinks it is menial labour as opposed to knowledge-dominated process. Move along, there is little understanding to acquire from this post.

I know right? Software development isn’t grilling burgers it’s designing the grilling system and building the entire supply chain to get it shipped to the customer that is*.

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

#90

Post by rubyist5eva »

langsoul-com wrote: post #61

I'd also add a large backlog of tasks is very depressing. If everyday you saw you had 100 more things to do and no matter how much you finish, the list doesn't go down, it's not exactly motivating.

Why? If the backlog is empty you don’t have a job anymore.
Post reply on HN