For my first job after university, I worked for a company with a ISO9001 certification. This meant that every project had a complete, documented process for every aspect, from reporting, to finance, to bug tracking, to code formatting.

There was even a team whose sole job was to define the template standards and enforce them across all projects. Most people thought they were busy-bodies, meddling with things they didn’t understand. While the team was staffed by people who had started doing project work, most had not done any for years.

In this piece, Seth Godin argues that understanding something is better than just memorising a process. Understanding is certainly key, but I think that misses something: there is value to in steps.

True, if you slavishly follow the steps, you can’t adapt. But if you don’t document the steps, it’s easy to miss one and get yourself into trouble. The challenge is knowing when to follow the steps and when to improvise.

I stumbled across “On git and cognitive load” and it got me thinking. That post led me to “Oh shit, git!?!” and that got me thinking further.

But first, a disclaimer: this is a post more about having perspective than providing answers. If I knew a better way, I’d be doing it.

The first blog argues that git is difficult to use. Further, that it was designed with the limitations of the time and that those limitations are no longer valid constraints. A decentralised system was required when poor network connections were the norm. Now we have cloud providers and ridiculous amounts of bandwidth.

The problem with “agile development” is that it is both a methodology and a buzzword. What this means in practice is that people who do not understand it implement parts of it without appreciating the whole. This usually results in more overhead but without the benefits.

I’ve come across this multiple times in my career. The usual refrain is “we’re agile so we don’t need documentation.” The “agile” aspect is more often than not, merely the assertion that the project is agile. Or someone says that the code is the documentation.