I wanted to document my stock, go-to approach for creating and sharing software architecture diagrams. It’s simple, low-maintenance because it lends itself to automation, and good enough most of the time. It’s not clever or groundbreaking, but might be useful if you’re looking to improve your documentation.

Roughly a year ago McKinsey and Company published an article entitled ‘Yes, you can measure software developer productivity’. It was a controversial piece, but did McKinsey introduce a genuine innovation?

Relying on manually reviewed pull requests to ensure that coding conventions are being followed? If you live in .NET land, don’t. Use custom Roslyn analyzers to spot and fix issues ahead of your CI pipeline.

Relying on manually reviewed pull requests to ensure that architecture constraints are being followed? Don’t. Instead, define the rules of your architecture and write unit tests to ensure they are not broken.

As a quick follow up to my piece on ditching blocking code reviews, here is an example of automating a check that is frequently done manually.

I expand on a conversation I had a couple of months ago, where I scoffed at workflows that manually approve pull requests before merging them without really explaining why.