Finishing what you start makes teams more productive and predictable • Hacker News Board

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

#101

Post by thejosh » Mon, Jul 25, 2022, 1:42 PM UTC

throw1234651234 wrote: post #97

thejosh wrote: post #95

Earlier quoted context omitted.

If your feature flags are behind such complexity you have a bigger problem than feature flags.

Note "serious work". If you are hiding a banner, an extra button that calls a service method used elsewhere, some text, etc - feature flag away. Real world problems tend to be, at the very least, "add some new fields to the form" - at which point you are messing with DB schemas OR following bad practices like making fields that should have no business being nullable accept nulls because "who knows if the feature flag…

Right... which is why I said It's a great way to do small-medium features.

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

#102

Post by snarf21 » Mon, Jul 25, 2022, 1:49 PM UTC

jmathai wrote: post #17

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…

This is the thing people miss with Agile processes. Agile without shipping is merely wasted churn. Nothing is more demotivating than wasted churn. Agile requires progress. How can everyone learn and re-evaluate if you always stay in same spot but just keeping turning in circles?

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

#103

Post by chiefalchemist » Mon, Jul 25, 2022, 1:54 PM UTC

> How finishing what you start makes teams more productive and predictable

What's even better? Starting the right things that deserve to be started in the first place.

Efficient !== Effective

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

#104

Post by knicholes » Mon, Jul 25, 2022, 1:57 PM UTC

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?

You could commit to something like, "Investigate the logs for two hours" or "inspect memory dump" for an hour. From there, one can add more detailed tasks.

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

#105

Post by BurningFrog » Mon, Jul 25, 2022, 2:01 PM UTC

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.

All that stuff is important, and I enjoy it more than most.

But I also keep in mind that the only point of it is to enable shipping more features faster and better.

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

#106

Post by ChadNauseam » Mon, Jul 25, 2022, 2:03 PM UTC

vitus wrote: post #65

ChadNauseam wrote: post #45

Earlier quoted context omitted.

A slightly better one: (committed + 1)/(completed + 2)

Wouldn't you prefer (committed + 1) / completed? Or (committed + 2) / (completed + 1)? In the limit, you want this to approach 1 (namely, you complete more or less everything you commit). A bad situation is where you're overcommitted and have many committed things, but few completed ones (e.g. 10/2), which results in a high ratio. But, with your proposed metric, you'd achieve the asymptotically ideal ratio with 2 com…

Haha, you're right, I meant `(completed + 1)/(committed + 2)`. A value close to 1 means you completed a lot of what you committed, and a value close to zero means you completed a very little. I stole it from Laplace's rule of succession.

[0]: https://en.wikipedia.org/wiki/Rule_of_succession

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

#107

Post by BurningFrog » Mon, Jul 25, 2022, 2:04 PM UTC

yakubin wrote: post #50

jraph wrote: post #42

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 seem like to have this kind of daily routine so your mileage may vary obviously. Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I…

> 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.

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

#108

Post by rekrsiv » Mon, Jul 25, 2022, 2:05 PM UTC

morelisp wrote: post #76

d0mine wrote: post #56

Earlier quoted context omitted.

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 dro…

It is also a rookie mistake to think that just because some tasks might blow up, you can't accurately estimate a large class of them to within a reasonable confidence window (say, within one day 99% of the time), and likewise identify those tasks with a large chance of blowing up. Breaking down tasks into smaller tasks seems to help build this skill faster in some people. If you don't want to be a mindless drone, you…

It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity budget prior to development without knowing the upper bound of your problem's complexity.

Some things still have to be discovered before they can be measured.

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

#109

Post by hallway_monitor » Mon, Jul 25, 2022, 2:12 PM UTC

kqr wrote: post #75

gravlaks wrote: post #33

Earlier quoted context omitted.

What kind of micromanagement did you experience / E.g. do you have an example? I'm in the position where I as tech lead don't fully know if I can trust my team (yet) to do the right decisions. One of the reason is that our product is quite new, and we haven't discussed developing principles yet. And some people tend to over engineer stuff all the time. But I also don't want to micromanage.

Can you prove that their "overengineering" makes things worse? And not just in the short term, but also for maintainability down the road, accounting for their developer experience and job satisfaction, etc? Otherwise maybe it's just a healthy level of engineering, knowing the details that person knows. The management advice I was given is that if you don't first trust people, they will never get a chance to show you…

Of course you can't prove that these four extra layers of abstraction will never be useful, but they aren't right now. That's why people with over 10 years in the industry are valuable - they have the intuition to see this coming.

The dev took twice as long to build the feature as they needed to, and updates to the code also take twice as long. I have seen this over and over, and GP is correct - there are some engineers who need to be coached out of overengineering.

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

#110

Post by jasonlotito » Mon, Jul 25, 2022, 2:22 PM UTC

The assumption here is that delivering the product is the finish line. That once you finish the burger, the person getting the burger is good to go and they can enjoy the burger. The problem is, restaurants don't work that way. If they delivered a single burger to a table, the guests would be upset and would wait. The person getting the burger would be waiting until everyone got their meal.

You need to deliver all the meals at once, and you need to prepare all the meals in such a way that they can all be delivered at once.

If you need to deliver 4 hamburgers, you prepare them in batches, and deliver them all at once.

Sending out the order in pieces makes the end result much worse for everyone involved. Which is why it's dangerous to look at delivering features as the end goal. You need to deliver a complete meals.

Sending out a single burger doesn't always make sense.