[from-nibly]

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.

[VyseofArcadia]

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

[feoren]

And everything is always a critical business initiative, because otherwise some senior manager is worried everyone will realize his job is pointless.

[from-nibly]

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.

[mihirchronicles]

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.

[necheffa]

> 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 whatever for refactoring.

That doesn't work in all cases, especially if the code base is particularly tangled. But you can get a lot of small things done this way.

[from-nibly]

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

[necheffa]

Your job, as an engineer, is to keep the ship battle ready. Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reigns and do what needs doing.

If there was no trust, they wouldn't be asking you to do the work in the first place.

Ridged top-down organizations wither away and die because they lack the agility and insight to respond to unexpected conditions. Leadership can set the high level goals of a mission, whether they like it or not, they need to also give the autonomy and authority to the field commanders to achieve those goals however they see fit.

If you are concerned your field commanders are going to go off and not stay focused on the goals then you've promoted too early.

The time for sitting around a table and talking openly at a higher organizational level is when deciding what goals to set, not in the heat of battle, unless it is to call a retreat.

It is only time to pack up when leadership is so full of itself that it cannot understand this.

Of course, you could argue that having a funding structure that necessitates padding in the first place is the early signs of the wheels coming off - which I would agree with.

[pvdoom]

> Not waste time by ceding control to another entity that doesn't have any engineering know-how to evaluate what does and does not need done. Take the reins and do what needs doing.

Problem is organisational power. What happens when the "another entity" is the one that has the decision making power and is the one that can use that power to pressure you what to do and what not to do?

Asking cause this was my life for a while, and its an endless and gruelling battle of persuading, educating, trying to make someone understand things they don't want to understand ...

[helge9210]

If they are also carry the responsibility over the wrong decisions, it's OK. If not, the organization is doomed.

[navane]

Blizzard wanted "Warcraft in Space". Designers came up with gameplay, which would be hard to implement in the existing warcraft engine. Engineering told the designers; we can do everything you want, but then we need extra time to build a new engine first. Everyone agreed and the best game of all time was made.

The 'refactor' was integral to the success of starcraft, and is definitely a tradeoff that needs to be weighed for new products.

[zzzzzzzzzz10]

And then they got bought by Activision and everything went to shit.

[rahimnathwani]

  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 the ops folks can live without (with some process change)?

- for #2, product folks can be helpful

[from-nibly]

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.

[rahimnathwani]

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

[antonvs]

Product folk hardly ever want to remove features.

[mihirchronicles]

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.

[pluto_modadic]

My (limited) understanding supporting developers for two years is that product does not take no for an answer, and controls everything from budget to sprints, and can insist on whatever they like, whenever they like. So... I'm going to take your comment as a lovely fantasy like spherical cows. Refactors are a joke that never gets off the ground, after a decade.

[sethammons]

In the healthy orgs I have worked in, it is a give and take relationship between product and engineering. Engineering should absolutely push back on some things and needs to also push for engineering specific projects. No spherical cows, just adults talking about needs and priorities.

The current place I am at has a history of eng doing anything product wants and not saying no or "yes and." As a result, the eng side is a mess, builds are slow, service and data boundaries are muddled, and shipping working software continues to slow. Incidents are rising and customers are starting to churn and larger customers are harder to sign.

As part of eng leadership, my role is helping teams learn what a healthy product and eng relationship looks like, which includes pushing back and gaining alignment on the need for eng focused projects.

[ElevenLathe]

So you will diligently improve the relationship and get things cleaned up, maybe even get credit for it, but the incentive for the next person in your post will be to cash out that built-up equity by saying "yes" to everything again and then getting promoted for their amazing velocity, nevermind that the code is now goulash again. I guess this is the cycle of basically every organization in human history.

[ozim]

That’s also how scrum should work you have the team that has burn down and by that you plan how much can be picked up.

Team should not be concerned by what to pick up but should be concerned by keeping the pace on the same level and if someone goes on vacation to make it clear for the product.

[pvdoom]

> Product should have nothing to do with refactors on the systems.

Which really sucks when product is the one that gets the say on what gets worked on ...

[feoren]

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.

[datavirtue]

This. It all boils down to shared vision and autonomy. All teams should be acting in concert for the same goal. If they aren't the board needs to cut the CEO yesterday and find someone who is going to foster a cooperative culture.

I work in a company where each team is aligned and has autonomy and trust, where people listen and find ways to help the other team. It's game theory with the right algorithm installed. Oddly enough, the company was founded during the peak of the military hierarchial taylorism cargo cult clusterfuck that bore mutants like GE. The military doesn't even work the way these companies operate.

[from-nibly]

OK