Live data from Hacker News

Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

news.ycombinator.com

1–10 of 75 posts

Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#1
Hey HN, Victor and Jacob here. We’re excited to show you what we’ve been building over the last couple of years! IcePanel (https://icepanel.io) helps architects and developers easily explain how their software works with interactive and explorable diagrams.

Modern systems are complicated, and getting new developers up to speed and contributing fully is time-consuming and difficult. It costs the new developer's time, as well as the time of the senior first/second generation developers who help them constantly through their first 6 months. The resources people use to learn new systems are usually scattered across a maze of artefacts, like confluence pages or outdated draw.io diagrams, which are usually incomplete, with the ‘real’ understanding of the system being tribal knowledge in the team. As discussed in yesterday’s post https://news.ycombinator.com/item?id=34328069 “documentation only works up to a point” and we believe this is due to docs being disconnected from the code. A map of your software architecture for current and future design, linked to code, gives new team members a trusted way to learn tribal knowledge.

Before IcePanel, Jacob was part of a cross-functional team in a large company, where they’d have regular meetings about the technical design. People would draw boxes and lines on a whiteboard or present Bollywood-themed Visio monstrosities that nobody truly understood (impossible to find in Confluence/Sharepoint). Depending on the people invited, 1-hour meetings cost the company thousands of dollars, and there were often no outcomes. We both felt the tools in this area were not working, and there was space to build something awesome.

We built IcePanel on top of the c4model.com, a simple set of abstractions for audiences with different technical abilities. The simplicity of the C4 model works well for teams who practice “just enough architecture,” and fits with a vision of democratizing architecture across dev teams. We also work with our larger customers to help with the scaling challenges of the C4 model and have built features like tags and flows that add interactive overlays on top of C4 diagrams.

Most diagramming tools are generic and flexible for any purpose. This is great for quick sketches and whiteboarding but painful for creating longer-term documentation where it’s important for objects to contain metadata and have relationships with other objects.

The benefit IcePanel has over diagramming tools such as draw.io/Visio is how it uses modelling, overlays and links to reality to keep your diagrams up-to-date and allow engineers to find the code they're interested in faster. Model changes are automatically synced across all diagrams, and you can refactor connections or the object hierarchy. We use interactive overlays to add/remove information rather than creating new diagrams for every new topic of conversation, meaning fewer diagrams to maintain. Objects in IcePanel can be linked to resources in the real world, such as source control, wiki pages or cloud resources. This allows developers to learn about resources of interest faster, and you’ll be alerted if those resources no longer exist, prompting you to update the model or diagram.

Thanks very much for reading! We’d be grateful to anyone who checks out our website (https://icepanel.io), interactive demo (https://s.icepanel.io/vmHvBHr4BeMEOa/bPBR) or leaves a comment with thoughts and feedback. Happy to chat!

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#2
This is very interesting. I had never heard of the C4 model before and will be using it going forward.

I'm skeptical that the current solution will be completely immune from doc rot but it certainly seems like there should be some way to generate/validate these diagrams from code. For example, there are many natural parallels between the flows diagrammed in your tool and setting up user journeys for E2E integration testing.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#3
Is the next step creating and updating these diagrams automatically? That dream seems to come up and die in cycles over the years, but it may be possible now depending on the compute platform and network appliances you use. This push to automate by doing interesting things, like reading your network traffic (https://www.akitasoftware.com/), could work here.

I'm unsure, as is, how you fix the organizational and human problem: It takes effort to initially create these diagrams, and constant work to keep them updated as systems evolve. How do you make that easier? A more fancy diagram explorer seems... not as useful.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#4
post #2

This is very interesting. I had never heard of the C4 model before and will be using it going forward. I'm skeptical that the current solution will be completely immune from doc rot but it certainly seems like there should be some way to generate/validate these diagrams from code. For example, there are many natural parallels between the flows diagrammed in your tool and setting up user journeys for E2E integration t…

We're big believers that the C4 model gives a good lightweight approach and guidance for those who struggle to articulate the complexities of software.

Currently the code checks work through manual set up and won't remove all doc rot for sure, but indicates when drift is happening. This helps both direct to what code/resources are of interest (onboarding new hires), and also checks it still exists in the source control. More smarter checks to continue removing doc rot are planned.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#5
post #3

Is the next step creating and updating these diagrams automatically? That dream seems to come up and die in cycles over the years, but it may be possible now depending on the compute platform and network appliances you use. This push to automate by doing interesting things, like reading your network traffic ( https://www.akitasoftware.com/ ), could work here. I'm unsure, as is, how you fix the organizational and huma…

Automatically generated diagrams seem to be the dream for many of the developers we chat to, however we don't see this working as great as they believe. This is due to "the model code gap" which is where the abstractions we use to discuss software architecture rarely matches 1:1 with the source code. You can read more about this on our blog article below.

https://blog.icepanel.io/2022/11/30/the-model-code-gap

We think this is more of a human/organizational problem rather than a technical one and we have tons of ideas about how to use links to reality to help humans keep docs up to date. For example an object which has had a lot of commit history recently probably needs the diagrams or docs updating.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#6
post #5
post #3

Is the next step creating and updating these diagrams automatically? That dream seems to come up and die in cycles over the years, but it may be possible now depending on the compute platform and network appliances you use. This push to automate by doing interesting things, like reading your network traffic ( https://www.akitasoftware.com/ ), could work here. I'm unsure, as is, how you fix the organizational and huma…

Automatically generated diagrams seem to be the dream for many of the developers we chat to, however we don't see this working as great as they believe. This is due to "the model code gap" which is where the abstractions we use to discuss software architecture rarely matches 1:1 with the source code. You can read more about this on our blog article below. https://blog.icepanel.io/2022/11/30/the-model-code-gap We thin…

I'm not sure I understand. A system diagram from source code or infrastructure alone is difficult, but adding some constraints and boundaries may help?

What if we only cared about http based services and the boundary is at the service layer? A sidecar running alongside your deployed service keeps track of incoming and outgoing network requests. Each sidecar is configured with metadata: The service name, hierarchy -- it belongs to this even larger service, it's this architecture, and using this runtime, ....

Collecting all of this telemetry along with the metadata would allow you to generate a graph of services in the entire system, who their callers are, and what they call, right? Even that's helpful as a starting point, where I can then go in and fill in the details. When I add a new service, it shows up automatically and is flagged for me to review.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#8
post #6
post #5

Earlier quoted context omitted.

Automatically generated diagrams seem to be the dream for many of the developers we chat to, however we don't see this working as great as they believe. This is due to "the model code gap" which is where the abstractions we use to discuss software architecture rarely matches 1:1 with the source code. You can read more about this on our blog article below. https://blog.icepanel.io/2022/11/30/the-model-code-gap We thin…

I'm not sure I understand. A system diagram from source code or infrastructure alone is difficult, but adding some constraints and boundaries may help? What if we only cared about http based services and the boundary is at the service layer? A sidecar running alongside your deployed service keeps track of incoming and outgoing network requests. Each sidecar is configured with metadata: The service name, hierarchy --…

Yeah that makes a lot of sense, we definitely believe there are automated ways to help speed up the modelling/diagramming process. Such as automatically populating certain levels of the model from resources in reality as you described. Possibly integrating with something like backstage.io could also be super interesting. Then you can create diagrams quicker from a pre-populated model.
Post reply on HN