7 ms·
Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs
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 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 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 https://icepanel.io), interactive demo (https://s.icepanel.io/vmHvBHr4BeMEOa/bPBR https://s.icepanel.io/vmHvBHr4BeMEOa/bPBR) or leaves a comment with thoughts and feedback. Happy to chat!
- sbuccini 4y agoThis 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.
- JacobShadbolt 4y agoWe'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.
- ctvo 4y agoIs 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/ 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.