Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unused hpos interface code #108

Open
alastairong1 opened this issue Aug 2, 2024 · 4 comments
Open

Unused hpos interface code #108

alastairong1 opened this issue Aug 2, 2024 · 4 comments

Comments

@alastairong1
Copy link

alastairong1 commented Aug 2, 2024

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
Copy link
Collaborator

Paterick commented Aug 2, 2024

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

@JettTech
Copy link
Contributor

JettTech commented Aug 2, 2024

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

@JettTech
Copy link
Contributor

JettTech commented Aug 2, 2024

@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
Copy link
Author

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:

  • He wasn't aware of this code and didn't use it (lack of coordination / communication)
  • ui-common-lib changes did not get adequately tested against Host Console (QA / regression needs)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants