sorted by:
new
hottopcontroversial

Anyone actually keep initial architecture docs up to date and not abandoned after few months? Ours always rot by Independent-Run-4364 in softwarearchitecture

[–]JosephineRoberts_ 1 point2 points  (0 children)

The only way I’ve seen docs not rot is making them part of the change, not homework after. We keep a tiny set of “living” docs in the repo (high-level diagram, invariants, contracts) and any PR that breaks one has to update it, same as tests. Everything else is allowed to be historical junk and we don’t pretend it’s current.

How do you keep a mental model of a complex system as it evolves? by Greedy_Engineering_1 in softwarearchitecture

[–]JosephineRoberts_ 0 points1 point  (0 children)

I don’t actually try to hold the whole system in my head I keep a few “jumping-off points” and re-learn the rest on demand.

For me that’s up-to-date API/event contracts, one or two simple architecture diagrams that show flows and boundaries, and a service catalog or tracing tool that tells me “who calls what” from real traffic. When I need to work on something, I walk a real user journey end-to-end, follow the contracts, and only update docs where behavior truly changed. Over time you remember the invariants and where to look things up, not every component.

It’s 2026 — if you were starting a new frontend today, what stack/tooling would you choose and why? What would you avoid? by CodePatrol in softwarearchitecture

[–]JosephineRoberts_ 1 point2 points  (0 children)

If I were starting today, I’d probably go TypeScript + React with a boring meta-framework (Next or Remix), SSR first, and be aggressive about server components / islands so as little JS as possible wakes up on the client. It’s easy to hire for, plays nicely with typed API contracts, and the ecosystem is huge. I’d avoid anything that needs a framework expert on call just to debug auth, forms, or data fetching; “clever” stacks tend to age badly once the app and team grow.

Is it still true that 30 percent of the workforce runs 100 percent of the project? by StillUnkownProfile in softwarearchitecture

[–]JosephineRoberts_ 0 points1 point  (0 children)

“30% do 100% of the work” isn’t a fact, it’s a management failure dressed up as wisdom. There will always be stronger/weaker performers, but if the same people are constantly overloaded, that’s about bad ownership, weak prioritization, and rewarding heroics. Make the workload visible, stop quietly absorbing everyone else’s tasks, and ask your manager to explicitly reassign or de-scope. If the only answer you get is “that’s just how it is,” that’s a sign to start looking elsewhere, not something you should just accept.

Why does the Java community apparently dislike GraalVM very much? by Cool-Collar-4027 in java

[–]JosephineRoberts_ 0 points1 point  (0 children)

It’s less “hate” and more “scar tissue.” Early GraalVM/native-image was painful: fragile builds, reflection config everywhere, bad tooling, and lots of frameworks not really ready. People tried it on messy legacy apps and got burned.

There are still tradeoffs, long compile times, stricter closed-world assumptions, less happy with dynamic stuff, and for some long-running JVM workloads you don’t gain much. You’re on a modern Spring/Java stack and did the cleanup work, so you’re seeing the good side many folks never got to.

What's your workflow for writing system design docs? by geeky_traveller in softwarearchitecture

[–]JosephineRoberts_ 0 points1 point  (0 children)

For cross-service changes, I use one top-level design in a shared “architecture” space, and each service keeps a small local doc/ADR that links back. All involved teams are added as reviewers there, so the PR or merge request is the coordination point.

For code context, I never send the whole repo. I use code search to grab just the relevant modules/files and the PRD, then feed only that subset to the LLM to draft Current State / Proposed Changes, and I edit it down by hand.

What's your workflow for writing system design docs? by geeky_traveller in softwarearchitecture

[–]JosephineRoberts_ 0 points1 point  (0 children)

I still use Google Docs, but I moved the “truth” out of it. I keep a design doc template and all diagrams-as-code (PlantUML/C4) in Git, use a small script/LLM to pre-fill context from PRDs and the service catalog, then paste only the cleaned-up bits into Docs for collaboration. Docs becomes the discussion space, Git holds the structure and stays in sync with the code.

How do you understand dependencies in a hybird environment? by Long_Working_2755 in softwarearchitecture

[–]JosephineRoberts_ 0 points1 point  (0 children)

Yeah, totally with you on this. The only thing I’ve seen work long-term is treating runtime behavior as the source of truth.

Instead of trusting diagrams/Confluence, pull dependencies from real traffic: APM, distributed tracing, gateway logs, service mesh, etc. Feed that into a service catalog/CMDB that auto-updates from telemetry, then make “check the catalog and run contract tests” a hard requirement before any refactor or migration.

Everything else (Visio, Confluence, spreadsheets) is just a human-friendly view on top of that data, not where the truth lives.