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

51–60 of 165 posts

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

#51

Post by jraph »

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.

Sure! I currently work at a place where there are deadlines and no sprints. It works very well for me, and for the company too apparently. There are customers who expect their stuff to be shipped and the product has a month by month roadmap.

Now, over-engineering is a risk but I think I'm lazy enough to avoid it most of the time. I probably have the opposite issue sometimes.

We do get things done without running for a deadline most of the time though, so it works okay without deadlines for the some non negligible part.

We'd be dead if we didn't release. There isn't any investor's money to compensate.

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

#52

Post by openfuture »

js8 wrote: post #48

If we all were just workers, it could work. In practice, I see lot of the high-level ideas/strategizing people starting new projects without finishing the old ones. They never bother with details required to finish or complete something. Starting and not completing is fundamental to labor division in capitalism, for better or worse. Without it, there would be less labor extraction.

Who knows if anything is finished anyway? So long as you live you can continue and the definitions are always in flux / personal.

I believe the one who feels the strongest pull should work on manifesting a vision, not the one who had the idea; i.e. if someone says "it'd be nice to have cake" and another goes "omfg yes that would be the best" then who should make it? They could do it together but if the first person shops for ingredients and then decides they'd rather go to hawaii for a bit then the second person can still make the cake and eat it without the world burning down.

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

#53

Post by openfuture »

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.

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

#54

Post by Archelaos »

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.

The problem is that deadlines are often too tight because the person responsible is usually not the one who suffers the most. If this is the case, the result is low code quality and bad feelings because the developers are either overworked or feel guilty. Instead, it is best to create a priority list of tasks and review it regularly.

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

#55

Post by Archelaos »

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?

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

#56

Post by d0mine »

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…

It is a rookie mistake to think that programming is splitting a big task into smaller tasks that are splitted into even smaller tasks, and that once the process is done, you can use mindless drones to complete these microtasks.

It assumes the perfect knowledge, the fixed work volume.

In practice, you don't know how much work might be required (a small task may blow up). It is inevitable that sometimes you have to drop features to ship in time. Programming is an iterative probabilistic process.

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

#57

Post by sokoloff »

topkai22 wrote: post #37
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…

This was the most glaring flaw of the post. They almost got there when they started talking about the “transaction costs” but failed to acknowledge idle times. To drive this home to software development, if I’m blocked on a requirements clarification, awaiting permissions to a data source, or blocked by a bug in an external system it certainly doesn’t make sense for me to just do nothing. I should pick up another tas…

For an expected short delay (like getting perms from an internal team), it might make sense to do nothing (on the product).

I usually have a backlog of administrivia and it makes sense to tackle some of that during a short blockage rather than open unrelated WIP.

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

#58

Post by Joel_Mckay »

Most projects go though several design cycles, and this usually starts with a theoretical goal or a proof-of-concept requirement. I have found that identifying the “hard” features first, and defining fixed time-budget micro-projects or key unit-tests is useful. Primarily, this method quickly identifies if a project is even viable with the available team, resources, and knowledge base.

Saying “No” to projects which incur serious liabilities, is just as important as minimizing project scope. Unconstrained sisyphean commitments are a common feature afflicting those with Founder's syndrome, and can have detrimental impact on projects as the intelligent begin to jump ship before it sinks.

Every firm that lives past 1 business cycle will have a project boneyard. ;)

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

#59

Post by miga »

Releasing is great, but the 80:20 principle means that finishing 80% of features and throwing away 20% is always much faster than expecting to finish 100%.

The difference between real life projects and college projects is that often nobody made the same feature in the same context before. This means that there will be features that will take much longer time, and need to be shifted to the next release or a bin for "complex enough to focus on everything else".

If you do not understand why something like this happens, it may be that you are unaware of the knowledge gains from exploration as opposed to releasing the product.

You just need one great product, and it is okay to throw away ten explorations to make it happen.

Post reply on HN