Architectural Retrospectives: The Key to Getting Better at Architecting | Hacker News Reader

Architectural Retrospectives: The Key to Getting Better at Architecting

infoq.com

38 pointsrbanffy16 comments

Architecture retrospectives sound like a good idea but don't seem to be "the key" because in practice they fail too often.

Retrospectives look backwards, and most teams aren't wired that way. And unlike sprint retrospectives, architecture retrospectives turn up issues that are unrealistic/impossible to adjust in real time.

Instead, try lightweight architectural decision records, during the selection process, at the start, when things are easiest to change, and can be the most flexible.

When teams try ADRs in practice, teamwork goes up, choices get better, and implementations get more realistic. And if someone later on wants to do a retrospective, then the key predictive information is right there in the ADR.

https://github.com/joelparkerhenderson/architecture-decision...

Is there already a good way to link an ADR Architectural Decision Record with Threat Modeling primitives and considerations?

"Because component_a doesn't support OAuth", "Because component_b doesn't supported signed cookies"

Threat Model: https://en.wikipedia.org/wiki/Threat_model

GH topic: threat-modeling: https://github.com/topics/threat-modeling

Real and hypothetical architectural security issues can be linked to CWE Common Weakness Enumeration URLs.

SBOM tools help to inventory components and versions in an existing architecture and to JOIN with vuln databases that publish in OSV OpenSSF Vulnerability Format, which is useful for CloudFuzz, too.

Good question. Yes there are a variety of ways that help.

1. If the team favors lightweight markdown, then add a markdown section for Threat Modeling and markdown links to references. Some teams favor doing this for more kinds of analysis, such as business analysis (e.g. SWOT) and environment analysis (e.g. PESTLE) and risk analysis (e.g. RAID).

2. If the team favors metrics systems, then consider trying a Jupyter notebook. I haven't personally tried this. Teams anecdotally tell me these can be excellent for showing probable effects.

3. If the team is required to use existing tooling such as tracking systems, such as for auditing and compliance, then consider writing the ADR within the tracking system and linking to it internally.

> 1.

Add clickable URL links to the reference material for whichever types of analyses.

> 2. Jupyter

Notebooks often omit test assertions that would be expected of a Python module with an associated tests/ directory.

With e.g. ipytest, you can run specific unit tests in notebook input cells (instead of testing the whole notebook).

There are various ways to template and/or parametrize notebooks; copy the template.ipynb and include the date/time in the filename__2024-01-01.ipynb, copy a template git repo and modify, jupyterlab_templates, papermill

> 3. [...] consider writing the ADR within the tracking system and linking to it internally

+1. A "meta issue" or an epic includes multiple other issues.

If you reference an issue as a list item in GFM GitHub-Flavored Markdown, GitHub will auto-embed the current issue title and closed/open status:

  - https://github.com/python/cpython/issues/1
  - python/cpython#1

This without the leading `- ` doesn't get the card embed though:

  https://github.com/python/cpython/issues/1

Whereas this form with hand-copied issue titles, non-obfuscated URLs you don't need to hover over to read, and - [ ] markdown checkboxes works with all issue trackers:

  - [ ] "Issue title" https://github.com/python/cpython/issues/1
  - [x] "Issue title" https://github.com/python/cpython/issues/2

thank you for sharing this! I'd seen formats similar to this but I'd never seen what the format itself is called. very helpful to see it clearly described - I think I'll try to give this a go with our teams

> Architectural Retrospectives differ from Architectural Reviews by focusing not on evaluating and improving the architecture itself, but on examining and improving how the team went about creating the architecture.

I don't think the purpose on a retrospective on product A is to improve product A, but to improve how product B gets built.

It's hilariously on point that this doesn't mention how any of this would in any way benefit the business. Don't get me wrong, I've spent my time in "architecture" to the point where I was part of the team which defined the national strategy for IT architecture in Denmark called Rammearkitekturen. I've yet to see any form of measured example where architectural work actually provided a measurable net benefit for an organisation though. In my experience it doesn't even lead to better code bases, because focusing too much on it tends to make people over complicate things to a ridiculous degree. Spending time both reviewing and retrospectiving and whatever other bloated pseudo-work terms various well paid consultants will come up with seems like a further waste of time. In my book.

Disclaimer: I think architects are pseudo-jobbers who should be replaced by a competent employee who will do actual work. Even in operations I tend to think having full time architects is a gigantic waste of resources. To me, full time architects are only ever going to fill the same role HR management advisors do, which is to make bad managers feel better about the decisions they take.

> I've yet to see any form of measured example where architectural work actually provided a measurable net benefit for an organisation though.

These things are hard to measure, but I've seen too much of the reverse as well: over-enthusiastic developers with no feel for the customer, no understanding of the domain, and no shared vision, but perfectly happy to ruin a codebase.

Especially in the field of having a shared vision, I think a good architect can do wonders.

I tend to see an architect as a multiplier for success. A good one has value above 1, the experiences you shared might have resulted in a negative one.

Edit: actually read the article, and boy do I agree with your sentiment now :)

I agree with everything you say. My personal issue is that I've very rarely seen the difference in impact by having full time architects. It's obviously very anecdotal, but in my experience, you can get both good and bad architecture regardless of it being governed by specialized architects or regular developers. I think the scale may even tip in the developers favour. It's probably important to point out that almost every Danish organisation is fairly tiny, even well past the startup phase. With that in mind, I'd always prefer a "regular" developer because they'll not bog things down with stuff like this article suggests.

> Edit: actually read the article, and boy do I agree with your sentiment now :)

Exactly, all I read was that I'd be spending even more of my time in useless meetings.

It's really hard to be a good architect, because their job is not supposed to be to leave their mark. An architect is doing a great job when the codebase is boring, and everybody talks about business. That doesn't help the architect however, because people can't tell how it would've been had they not been there. "Our codebase is so simple and boring, why do we even need an architect". That's how you get the kind of architects that try to look impressive to the management.

There are a few things a business can do to get a good kind of architect.

1. Hire them to be hands on with code (give them secondary features or refactors, not major lifts, since shipping speed is not the priority). 2. Don't give them authority over devs, rather ask them to provide mentorship and demos. Their job is to excite devs about a clearly better approach, not to force their opinion. 3. Encourage devs to come to the architect for advice as needed. 4. Have the architect organize long term refactors[1] when needed.

Basically make them a developer whose audience is other developers, and the product of their work is developer buy-in/excitement over good practices and software design directions.

[1]: https://max.engineer/long-term-refactors

I completely agree with you. To me a good architect is someone who enhances software developers and if not mentors them then guides them in the same direction. Unfortunately there are simply so many barriers in the way of this ever becoming an actual option in most organisations.

You'll need this unicorn situation where you have architects with very good social, communication and change management skills who are also technical apt and very good at dealing with "developers". I put developers in quotes because if we're honest with ourselves we all know that we're probably one of the most unmanageable groups of employees out there. This is the easy part. The hard part is to find an organisation which will give your architects and software developers the time they need to actually perform this sort of work, and, you need IT management with clear role definitions so it doesn't end up in a confusing mess where nobody really knows who can decide anything.

Since this rarely happens, most architects either become managers or go back to being developers leaving only the people who actually enjoy the "process" more than "results" being long time architects. Obviously not in 100% of the cases, but in most of them. There is nothing I personally dislike more than "process" people. I used to think of them as an unecessary evil that I just didn't understand, but then Covid happened while I was working in a 6000 employee organisation. Virtually every one of our "process" people was unable of doing any sort of work for 9 months, and during those 9 months our production and employee happiness sky-rocketed across every field. Well... happiness didn't increase for middle managers or "process" people, but...

I'd go as far as to say good architecture is an invisible enabler.

You don't think about the work that went inside Ruby on Rails to structure its functionality in a way Rails developers find productive and comfortable.

At the same time, another kind of architect, Oscar Niemeyer, has a good reputation between those who admire his works, and a very different one (sometimes good, but often terrible) from those who have to live and work in his buildings.

Architects of all kinds walk the thin line between elegance and practicality.

Besides, architectures often need to change when the implementation finds assumptions that aren’t holding.

The one benefit I see is: ensuring everyone follows a standard ‘blessed’ way, and contain the chaos a bit.

What I dislike about most architecture people is the lack of care they tend to have to handle a gradual transition from one architecture to another. This part tends to cost much more than they care.

> The one benefit I see is: ensuring everyone follows a standard ‘blessed’ way, and contain the chaos a bit.

Never underestimate the ability of a couple hundred developers (and users, POs, domain experts and so on) for creating chaos. The fight is real.

BTW, I was once nicknamed Dr. No.

Some large public examples of where software architectural work provides a large benefit:

1. Amazon all-in on API service architecture thus creating Amazon Web Services.

2. Sun all-in on attempting run-anywhere architecture thus creating the Java Virtual Machine.

3. Facebook all-in on PHP single-page rendering architecture thus creating HipHop.

4. Linus all-in on Unix x86 architecture thus creating Linux, then all-in on distributed versioning architecture thus creating Git.

5. Google all-in on horizontal scale architecture thus creating Bigtable, MapReduce, Kubernetes, etc.

6. Apple all-in on vertical device architecture thus creating Apple Silicon, iPod/iPhone, physical stores, etc.

7. Hashicorp all-in on infrastructure as code architecture thus creating Terraform, Vault, etc.

8. 37signals all-in on convention-over-configuration MVC web app architecture thus creating Ruby on Rails.

9. NVIDIA all-in on GPUs thus creating CUDA and enabling matrix math speedups of many programs.

> architects should be replaced by a competent employee who will do actual work

To me this sounds like "police should be replaced with citizens not breaking the law". It would be great, except it's impossible.

Reply on news.ycombinator.com