Live data from Hacker News

Ask HN: Visualizing software designs, especially of large systems (if at all)?

news.ycombinator.com

121–129 of 129 posts

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#121
Seeing as there are so many tools and no one is using them, it makes me think that they are just too hard to maintain separately from the system itself. Keeping a readme up to date is hard enough.

A good tool needs to be automatically generated from code which makes me think it needs to be integrated in a framework. Or the code needs to be written in a way that is easily visualizable in the first place.

Code comments seem to be the only way to add structure while ensuring the diagrams are kept up to date.

I think there is room for future frameworks that are built with visualization and it’s necessary tooling as a first class priority. When have you ever seen a framework claim it is easy to visualize and understand? Existing software is too much of a mess.

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#122

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes . At the moment, codeatlas is only a static galle…

That is really sweet, I love it! You've both done a really fantastic job.

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#123

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes . At the moment, codeatlas is only a static galle…

Very interesting! I'm convinced humans looking at code plots can see things that computers can't. An extension of your idea is to show how code changes over time. Sections that don't change much = "backbone" of system, probably bug-free. New code, or code that changes a lot = "sketchy", might have bugs. Alternatively, show code colored by "quality" i.e. complexity.

Here's my take: https://github.com/johntellsall/shotglass#demo-flask-a-small...

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#124

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes . At the moment, codeatlas is only a static galle…

Will it be a paid product?

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#125

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes . At the moment, codeatlas is only a static galle…

That is really sweet, I love it! You've both done a really fantastic job.

Thanks - we're really excited to finally get some feedback on this! :)

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#126

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes . At the moment, codeatlas is only a static galle…

Very interesting! I'm convinced humans looking at code plots can see things that computers can't. An extension of your idea is to show how code changes over time. Sections that don't change much = "backbone" of system, probably bug-free. New code, or code that changes a lot = "sketchy", might have bugs. Alternatively, show code colored by "quality" i.e. complexity. Here's my take: https://github.com/johntellsall/shot…

Huh, I hadn't thought about it that way - you're right, infrequent changes could indeed be a good proxy for stability! (or for "dead-and-forgotten" :D)

Complexity is an interesting measure too - I'm currently not sure how we'd model this, but this could definitely help codeowners understand which parts of their codebase is currently difficult for people to wrap their heads around. Or whether there's any complex parts that there's only a single contributor to, without whom the project would be left with a serious knowledge gap.

Once this can run as part of a CI pipeline and thus lives directly in the repo, I'd also love to add an overlay with the output of the testsuite to see which parts of the codebase aren't covered by tests! Or the output of a profiler, to see which functions are actually called the most.

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#127

Earlier quoted context omitted.

Very interesting! I'm convinced humans looking at code plots can see things that computers can't. An extension of your idea is to show how code changes over time. Sections that don't change much = "backbone" of system, probably bug-free. New code, or code that changes a lot = "sketchy", might have bugs. Alternatively, show code colored by "quality" i.e. complexity. Here's my take: https://github.com/johntellsall/shot…

Huh, I hadn't thought about it that way - you're right, infrequent changes could indeed be a good proxy for stability! (or for "dead-and-forgotten" :D) Complexity is an interesting measure too - I'm currently not sure how we'd model this, but this could definitely help codeowners understand which parts of their codebase is currently difficult for people to wrap their heads around. Or whether there's any complex parts…

Complexity is relatively easy. It's basically the number of loops and conditionals in a function :) https://thevaluable.dev/complexity_metrics_application/

The testsuite overlay sounds wonderful. Or maybe "coverage multiplied by business value". Biz-important things like authorization or money = more coverage, random marketing things = less important for test coverage.

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#128

My friend and I have been working on https://www.codeatlas.dev in our spare time, which is a tool that creates pretty (2D!) visualisations of codebases, while providing additional insights via overlays (e.g. commit density, programming language). For example here's the Kubernetes codebase visualised using codeatlas: https://www.codeatlas.dev/repo/kubernetes/kubernetes . At the moment, codeatlas is only a static galle…

Will it be a paid product?

Hmm - at some point we'll have to think about how fund further development, but the current plan for the github action is for it to be open-source (under a BSL-like license) and free to use!

Re: Ask HN: Visualizing software designs, especially of large systems (if at all)?

#129
I’ve done the print and trace for bizarre bugs while trying to understand the code. I’ve also used UML to work through designing something, or even changing the existing design. UML can be super helpful is working out programming problems without having to spend time writing the code. Your design problems can be worked out quickly with UML. Once you get your design work done and settle on an implementation, the individual class diagrams help determine your order of operations and what you may need to do for the refactoring (which, again, you can plan out in UML). Executing the plan becomes a matter of implementing your UML designs.

I’ve recently realized that UML is no longer something new developers are aware of. It’s a useful tool in reducing your time for solving problems since you won’t have to write the code as you work through them.

Post reply on HN