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

Monkey Management

mihirchronicles.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Monkey Management

#21

Post by from-nibly »

VyseofArcadia wrote: post #13
from-nibly wrote: post #11

I know this wasnt what the article was about. However... Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. Engineering needs to own their own availability to product. Engineering cant be 100% available to product and engineering needs to grow up and state their availability to product.

I think in the real world, what almost always happens is, "it looks like you're dedicated x capacity to technical debt reduction, but this is a critical business initiative, so you need to defer that and work on new features."

It better be a critical business initiative otherwise why are we even talking. Product better not be coming to me with half thought through optional BS.

Re: Monkey Management

#22

Post by from-nibly »

necheffa wrote: post #20
from-nibly wrote: post #11

I know this wasnt what the article was about. However... Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. Engineering needs to own their own availability to product. Engineering cant be 100% available to product and engineering needs to grow up and state their availability to product.

> Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. In practice, Product often controls the budget. So even if Product doesn't have the explicit power to veto a refactor, they have a lot of implicit power to deny this by only allocating enough to get a feature done. Now if you care, you just pad estimates and don't mention that there is a 20% tax or whateve…

When we cant communicate honnestly its time to pack it up. If there is not trust how can you get anything done?

Re: Monkey Management

#23

Post by from-nibly »

rahimnathwani wrote: post #16
from-nibly wrote: post #11

I know this wasnt what the article was about. However... Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. Engineering needs to own their own availability to product. Engineering cant be 100% available to product and engineering needs to grow up and state their availability to product.

Product should have nothing to do with refactors on the systems. Let's assume the reasons to refactor are: 1. Reduce unnecessary complexity, and 2. Reduce the gap between the code architecture and our current understanding of the domain. Sure, you could refactor and preserve 100% of existing system behaviour, but: - why not take the opportunity to discover the remove features that are annoying to maintain, but that t…

I meant refactor extremely broadly. As in the stuff that doesnt make customers happy, it makes engineering more effective at their jobs so they can deliver faster.

That includes refactoring, pruning, training, scaling, vendoring, etc.

Re: Monkey Management

#24

Post by from-nibly »

feoren wrote: post #15
from-nibly wrote: post #11

I know this wasnt what the article was about. However... Product should have nothing to do with refactors on the systems. That should be an engineering responsibility. Engineering needs to own their own availability to product. Engineering cant be 100% available to product and engineering needs to grow up and state their availability to product.

This reminds me of those useless articles like "Donald Trump should resign". Okay, and? We should all have mansions and sex robots. It's utterly pointless to pontificate about should ; it makes it sound like you have no understanding of the actual real world. In the real world, your company is run by pathetic parasitic asshole narcissists who will never give half a shit what anyone like you thinks.

OK

Re: Monkey Management

#25

Post by rahimnathwani »

from-nibly wrote: post #23
rahimnathwani wrote: post #16

Earlier quoted context omitted.

Product should have nothing to do with refactors on the systems. Let's assume the reasons to refactor are: 1. Reduce unnecessary complexity, and 2. Reduce the gap between the code architecture and our current understanding of the domain. Sure, you could refactor and preserve 100% of existing system behaviour, but: - why not take the opportunity to discover the remove features that are annoying to maintain, but that t…

I meant refactor extremely broadly. As in the stuff that doesnt make customers happy, it makes engineering more effective at their jobs so they can deliver faster. That includes refactoring, pruning, training, scaling, vendoring, etc.

Yes, but with this approach you risk spending effort refactoring code that could instead be deleted.

Re: Monkey Management

#26

Post by benreesman »

This is kind of adversarial sounding.

I’ve been in some messed up teams, but by the time it’s the blame game, I feel like people have stopped pretending?

Once the incentives are corrupted your business is living on borrowed time. But people generally agree (at least in private) when that’s happened.

YMMV.

Re: Monkey Management

#27

Post by antonvs »

rahimnathwani wrote: post #25
from-nibly wrote: post #23

Earlier quoted context omitted.

I meant refactor extremely broadly. As in the stuff that doesnt make customers happy, it makes engineering more effective at their jobs so they can deliver faster. That includes refactoring, pruning, training, scaling, vendoring, etc.

Yes, but with this approach you risk spending effort refactoring code that could instead be deleted.

Product folk hardly ever want to remove features.

Re: Monkey Management

#28

Post by beryilma »

> It was boss-imposed meaning it cannot be disregarded by Product team. It is expected to deliver otherwise the team will face penalty.

This is often the problem. The bosses impose fad of the day as the next thing to work on and expect everybody to be excited about it. And the fads keep changing year after year. And when the managers try to pass the monkey to software engineers, in my case, engineers do a half-ass job because they don't care about the new fad.

Re: Monkey Management

#29

Post by mihirchronicles »

from-nibly wrote: post #21
VyseofArcadia wrote: post #13

Earlier quoted context omitted.

I think in the real world, what almost always happens is, "it looks like you're dedicated x capacity to technical debt reduction, but this is a critical business initiative, so you need to defer that and work on new features."

It better be a critical business initiative otherwise why are we even talking. Product better not be coming to me with half thought through optional BS.

Fair. The problem is that neither design nor development will size the request until product gives them a priority but product cannot prioritize till they get a size. And the going around circle continues.

Re: Monkey Management

#30

Post by mihirchronicles »

antonvs wrote: post #27
rahimnathwani wrote: post #25

Earlier quoted context omitted.

Yes, but with this approach you risk spending effort refactoring code that could instead be deleted.

Product folk hardly ever want to remove features.

There is a lot of fear in sunsetting features. This could be due to friction in how long it takes to develop. For example, consumer technology does a better job than regulated industries such as finance or healthcare.
Post reply on HN