Open alastairong1 opened 1 month ago
Hi @alastairong1,
I wanted to provide some clarity on the purpose of the ui-common-library repository and its importance:
Purpose of the Repository: The repository was created to maintain consistency in shared UI and interfaces between teams.
Shared Component Dependencies: The HPOS Rust API is a shared component with cross-team dependencies. The goal of having a shared library is to ensure that if the interface changes, it only needs to be updated in one place, allowing all UIs to inherit the update seamlessly.
Current Usage: Holofuel, Cloud Console, and Host Console all use the UI Common library, with Holofuel and Cloud Console utilizing this shared HPOS interface code. If the Host Console were also using this interface code, we could have avoided the sync issues experienced last week.
Productivity Measurements: Regarding productivity benefits, it's challenging to quantify a "50x productivity benefit vs. a 10x benefit" as this is a subjective measurement. We aim to follow software development standards and best practices, and having shared code in a shared library seems to align well with these practices.
Please let me know if there's anything specific you'd like to discuss further.
Best,
Patrick cc: @JettTech @robbiecarlton @pandeyAK
@Paterick - I totally agree with everything you said. Thanks for the response.
@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.
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.
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