←back to thread

261 points david927 | 3 comments | | HN request time: 0s | source

What are you working on? Any new ideas that you're thinking about?
Show context
jtwaleson ◴[] No.43157056[source]
I'm creating an infinite canvas that has all your organization's code and documentation on it. If you zoom in, you can see the code, if you zoom out you see the big picture. By giving everything a place on the map, it becomes easier to figure out your way through the landscape and understand the systems. Different modes can you show you different things: code age, authorship (bus-factor, is the person still with the company etc), languages used, security issues. There's time-travel, think Gource for all software in your company, and maybe the most fun: a GeoGuessr for code. Select the repos for your team (or if you feel confident, of the entire org), you get a snippet and have to guess where it is. The plan is for LLMs + tree-sitter to analyze all the code and show relations to other systems, databases etc.

I had the idea 2 years ago, but starting building in earnest 2 months ago. Spending all my time on it now, minus 3 or 4 days per week of earning money. Currently looking for a GTM/sales-oriented cofounder in NL.

replies(20): >>43157073 #>>43157136 #>>43157178 #>>43157780 #>>43158134 #>>43158368 #>>43158505 #>>43158526 #>>43158634 #>>43158984 #>>43159227 #>>43159992 #>>43160392 #>>43161555 #>>43161560 #>>43162756 #>>43164555 #>>43172370 #>>43196913 #>>43256135 #
svilen_dobrev ◴[] No.43162756[source]
mapping the software items (and whatever related)... has been a conquest ever since. Although what you may infer without knowing deeper essential details (engines and what data drives them how), would be static. Still, "communication diagrams" are very useful meta-view.

some suggestions:

* have ways for multiple views and/or start-points and/or both up/down directions. e.g. hierachy vs reason/effect vs dependence vs whatever-else. Then think about animating those in time

* heat-map over the views, as e.g. churn(changes)-in-time, or usage(number of dependents), etc

* requirements engineering kind-of-view ~ may overlap with dependency (both directions!) but with explicit requirements/assumptions tied to respective stakeholders. Though this may need links to/from JIRA and similar issue-trackers etc

* check Wardley maps - yet another view, starting from customer/stakeholder/vendor-points. Also may move in time. It may need user decision on which things are big/separate-enough to surface on that view - sometimes a single script is on-par with whole subsystem

* future maybe - growing above into zoomable per-project thing (more proj.mngmnt than just code, incl. related e-mails etc) - described here: https://news.ycombinator.com/item?id=43060108

* probably more.. will add if something else dawns on me

have fun!

p.s. fractional CTO? i am looking that way too..

replies(1): >>43164901 #
1. svilen_dobrev ◴[] No.43164901[source]
* runtime-statics i.e. DevOps-view.. like what runs on which machine - maybe derived from container-descriptions? also bi-directional
replies(1): >>43165206 #
2. jtwaleson ◴[] No.43165206[source]
Lots of good ideas in your comments, thanks. Like you say, you want call-graphs, hot-spots from your monitoring systems, seeing user interaction diagrams, links to other components, amount of engineering time spent on features, mapping security issues, tech debt, etc. The challenge is going to be to keep a simple product :)
replies(1): >>43171021 #
3. svilen_dobrev ◴[] No.43171021[source]
These are not meant to distract you from current goals/ways - pick those which ~80% match what you already have, postpone/abandon the others. Like, devOps view is very different from all else, with somewhat weak links across to the product-related or build-related views (heh, new view: costs-related. Be them people-hours or compute/storage). No need to compete with focused tools in that space, (e.g. see [0]). Though some linkage/hints might be doable and valuable. (also see some github-repo visualizers below.)

3+ years ago i landed as architect onto a working system having 300Kloc js codebase across 20+ repos, plus other ~100 unused ones with unknown Mlocs in them, running over 25+ containers in 2 datacenters.. without neither good architectural diagram nor deployment diagram nor runtime flow diagram... took me quite some months to build some mental image of which is what and where and why. It was event-sourcing engine so event-flows mapping from parsing the source was doable (few weeks, python+esprima+graphviz), but all else... nope.

Anyway, do ping me if you feel like it, any time.

----

[0] https://news.ycombinator.com/item?id=43161332 - subimage.io

[1] https://news.ycombinator.com/item?id=42521769 - gitdiagram.com

[2] https://news.ycombinator.com/item?id=42976467 (manned service?)

[3] https://news.ycombinator.com/item?id=41393458 - codeviz.ai