Holo-Host / ui-common-library

Common UI library code
MIT License
39 stars 1 forks source link

Unused hpos interface code #108

Open alastairong1 opened 1 month ago

alastairong1 commented 1 month ago

The services/hpos.js code appears to be unused. Host Console has it's own internal logic for handling this so this looks to be duplicate code.

If it is actually used, then IMO we need to stop using it.

As a critical guiding principle, we must avoid creating cross-team dependencies except where absolutely necessary.

I would assert that a guiding rule of absolutely necessary is "If it generates 50x productivity benefit" because the cost is at least 10x from cross-team coordination across timezones and the huge velocity drag and mental overhead that creates.

@JettTech @Paterick @robbiecarlton

Paterick commented 1 month ago

Hi @alastairong1,

I wanted to provide some clarity on the purpose of the ui-common-library repository and its importance:

Please let me know if there's anything specific you'd like to discuss further.

Best,

Patrick cc: @JettTech @robbiecarlton @pandeyAK

JettTech commented 1 month ago

@Paterick - I totally agree with everything you said. Thanks for the response.

JettTech commented 1 month ago

@alastairong1 - Can you please help me understand more about how this repo creates a cross team dependency? @mateuszRybczonek and @Paterick are both codeowners on this repo.

alastairong1 commented 1 month ago

Firstly, it now occurs to me that HoloFuel UI has a Host version and I'm assuming that is what uses this code. So this specific issue is moot.

But because of the conversation here I'm going to get on my soapbox a bit as this is a topic of great importance to me :)

I made this post having reflected on two observations I had from speaking to Mateusz:

Let's start by backing up a bit and asking "Why is it important to maintain consistency?" As Patrick stated, it's so we only need to maintain code in 1 place.

But if you look at our software development processes, our primary bottlenecks are not in writing and maintaining code. They are cross-team coordination and QA/regression testing. Upstream dependencies mean that work for one team's story can now break the other team's deployments, so we've created new coordination and QA regression testing needs. We must avoid optimising for the wrong thing and inadvertently putting more strain on our bottleneck areas.

That's not to say that there's no place for shared internal dependencies, and now is not the time for us to start rethinking how this all works and paying more attention to software development lifecycles and supply chains. But if there's one rule of thumb for me, it's Say no to cross-team.