Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs
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!
74 comments
[ 0.33 ms ] story [ 596 ms ] threadI'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.
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.
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.
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.
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.
This is one of my primary goals with Ilograph[0] because, as you noted, diagrams that are hard to maintain don't get maintained (and very quickly lose value). It takes a three-pronged approach to solving it:
1. Model-based diagramming. All components in the diagram are part of a model. This means components can be used in many different diagrams (called perspectives in Ilograph) and kept in sync. It's kind of like having static type checking for your diagrams.
2. Diagrams are 100% laid out by machine. Diagrams created using drag-and-drop tools are practicably unmaintainable[1].
3. Perhaps most important, the tool has a full IDE with autocompletion to assist with developer ergonomics. Every little bit helps.
[0] https://app.ilograph.com/ [1] https://www.ilograph.com/blog/posts/its-time-to-drop-drag-an...
0: https://mermaid.js.org/intro/
I'm curious what JavaScript/React libraries do you use to generate your lines and boxes visuals?
I'm looking for something like tldraw[0] for Vue.
0 - https://github.com/tldraw/tldraw
- normal scroll (instead of ctrl+scroll which is typically used for making text larger) for zooming in / out
- holding center mouse button to pan around (currently scrolls page instead)
Middle mouse drag should definitely pan.
https://stackoverflow.com/questions/10744645/detect-touchpad...
You should probably be thinking of it the opposite way, is there a reason people wouldn’t use it on their phones? It’s on the web, the web is on your phone! People use their phones all the time for work-related things so they are going to expect this to be available there, too.
https://www.youtube.com/watch?v=36OTe7LNd6M
I'd suggest to change this copy writing to "any purpose - which is great". Was a bit confused while reading, had a bit of disconnect.
I do have some concerns on pricing. $30-40/editor/month is pretty steep! Unless there are good tools for managing swapping users in and out of "reader" vs "editor" states across billing cycles, I think a lot of orgs will balk at this pricing. I know mine will if 98% of our ENG team isn't editing except maybe once a year.
We have ideas to increase the capability of readers to make edit suggestions, that can be accepted by an editor. This way you can have some of the more junior team members included in the reader count.
How would this sound for you?
Ultimately, I'm not just not sure what the right billing model here is. Obviously, I want to pay a "reasonable amount", but I understand you need that model to have some kind of payment floor. :)
Some major components of usage/pricing that I can think of:
- Domain Owners - some users will be subject matter experts or DRIs that have ownership over parts of the overall model. These are more likely to be editors, but even other engineers may have small tweaks (edit suggestions) for a domain someone owns
- Any given engineering user will probably not be editing for the vast majority of the time. This + your existing pricing model + edit suggestions would lead to "editors" functioning more as just "approvers". It pushes an org to have a handful of approvers and the rest of their users as commenters.
- high price anchoring - $40/user/month sounds like a lot, even if it's for only a few users. It's also a more complicated user model that makes it more difficult to integrate into IT organizations. It is easier to integrate all users uniformly at a lower price per seat. And if I have 10 people on my team, $4/user/month is the same as having one editor but far more palatable (to me).
We're a <10 person start-up. $40/mo seems too much relative to how often we'd use the tool. I would use this tool if there was a cheaper option ($10/mo/editor) for a team of our size.
It would probably be much easier to understand if it was a system I worked on every day.
https://s.icepanel.io/vmHvBHr4BeMEOa/0YRL
Loved the concept, found it fell over for real-sized things on even the most powerful machines, had to switch to Structurizr to do our C4 modeling: https://structurizr.com/
Was very disappointed, bet I'd get more devs to model architecture with this tool. If it's relaunching because perf problems were resolved, will look forward to try it again.
Depending on scope of people's needs, either highly recommended or, try it first.
Hats off to Victor for great support back then, and I see the docs are a reflection of that, like this section on embedding into popular tools:
https://docs.icepanel.io/features/sharing#embedding-share-li...
TL;DR: Helpful team, thoughtful UI, thoughtful docs, a product capability (c4 modeling) very worth understanding and using.
We've been working hard to improve our performance/scalability for large models over the last couple of years. We shipped major updates in this area recently so I'd be interested to hear when you last used the tool.
I'd love to dig into what issues you had so we can make sure they're resolved for you/other people.
Please reach out to me at mail@icepanel.io
Would you be willing to elaborate a bit on what frameworks, tools, and technologies are used to create IcePanel? Anything you're willing to share, and specifically I'm curious if you used React Flow.
For the canvas we use https://pixijs.com, it's super powerful/performant and works well for us.
As an employee however; nobody on my team, nor my projects, nor my wider organisation will spend the time to keep these updated.
We can barely keep public-facing API documentation up-to-date. Diagrams like this are an order of magnitude harder to keep up-to-date, and Solution Architects will refuse to go to this level of detail, as they'd actually have to think through the problem and do some actual system design.
But as a consultant, I'm going to use this in my kick-off projects and my proof-of-concepts, and it's going to dazzle everyone. But maybe 5% of my clients would pay me to do detailed diagrams or documentation like this.
EDIT: OK, unfortunately the initial onboarding is overwhelming and underwhelming at the same time. I'm used to ArchiMate, I'm used to draw.io, I'm used to Visio, I'm used to plantUML. You've taken some of the existing design patterns but made them different enough it feels uncomfortable.
The initial onboarding needs significantly more work. Dumb down the default, initial view. I don't need "Start Trial", I don't need "Help", I don't need "Invite", I don't need "Embed", I don't need whatever the fuck "Landscape recommendations" is, I don't need wait what the fuck is "Link to reality" and how is it different to the "Share" part of "Embed and Share"? Why is there some sort of animal I can't make out with a party hat on it next to it? Oh Link to reality is a "fun" play on syncing with a backend repo.