Tag Archives: process

Is git too hard

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 second post notes that people keep getting themselves into a bind, with some helpful tips on extricating yourself from those situations.

The fun thing to note here is the kinds of problems that we need to solve with git:

  • I missed a file from a commit
  • I put the wrong commit message
  • I put committed a change on the wrong branch
  • I need to remove a commit

To me, the fascinating thing about all of these things is that in the systems that came before git, it wasn’t possible to do any of them. Once you made a commit in Subversion, that was it. It was in the repository and immutable1.

Missed a file from a commit? Shrug

Committed something you shouldn’t have? Tough2

Also, in the late 2000s, when git was just starting to take off, an argument against switching was that the commit history was not sacrosanct; the record could be changed. Subversion’s behaviour was a feature not a bug.

In the next decade, we’ve changed mindset so much that the ability to change a commit is now expected, even when we know that it can cause problems.

Similarly, while git’s distributed nature certainly adds to its complexity, it’s both fantastically useful and not a source of its worst behaviours. I can sit on a plane with no internet access and still have most features. I can move my repo between cloud providers or host my own. When my broadband or AWS goes down, I can continue working.

Maybe rather than move to a proprietary, cloud-based source control system — which is what the author of the first piece is really advocating — we should remember what we gained when we moved last time.

Git is tricky. But rather than return to a centralised system maybe we should fix git’s user interface. Being able to fix past commits is useful, though we we should be able to do so without messing up our code or, especially, the code repository.


  1. As ever, it was always possible to hack the repo but in my experience this was frowned upon. ↩︎
  2. I do remember a time when someone committed a password. It took a lot of time and expertise to scrub it from the history. ↩︎

Fragile Development

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.

Another common one is “we need to improve communication so we’ll have have a daily stand-up.” This often ends up being an opportunity for senior managers to give ten minute monologues about what they might get up to if they didn’t have so many meetings to attend. (Cue unheeded calls for sympathy.) Updates from people at the coal face often get cut due to time pressures. After a few weeks people stop attending…

Agile as it was originally designed was clever because it went up against the common wisdom of the day by jettisoning certain elements of bureaucracy but balancing them with other carefully considered, and hopefully less onerous, procedures. Less documentation might work if you increase the amount of teamwork; less formal requirements gathering is counteracted by including a user in the team; regular cadence of releases means you can get away with less rigid planning.

The common trait in the examples I gave is that they lack that balance. Not writing documentation is a mistake if there is no other method of retaining knowledge inside an organisation. Poor communication is not solved by managers broadcasting how out of touch they are.

As with any problem, you can’t fix it if you don’t understand it.