Let’s talk about automation. This seems like an out of place thing in this series. Predictable! Prioritized! Connected! Accountable! These are all fuzzy people things. Automated sounds like… more fun? Like Proper Developer Work?

Automation is like documentation, but developers might actually write it.

Without automation:

• It’s easy to have random esoteric things that few people know how to do.
• It’s harder for others to take over process like builds.
• A lot of time is spent on manual processes that are straightforward to reproduce (e.g. basic QA).
  • Either bugs are missed because this is inconsistent.
  • …or at takes time that could be better used elsewhere – e.g. more complex scenario testing for QA professionals.

What can we automate?

Automate builds. Seriously. If you commit to predictable releases, you will end up investing in automation to maintain that process – otherwise it’s too painful. This includes things like scripting translations etc. There’s a chicken and egg problem there, where push back on regular releases can be lack of automation. But I’ve found there are few things more motivating for motivation than regular releases.

Write tests. I can’t believe I’m still trying to convince people tests are important in 2017. One of my current work hobbies is noticing GitHub threads with clear testing instructions for reviewers and commenting “this would make a good automated test”. Other common GitHub comments from me: “can you add some tests, please?” And “I like these tests.”

Add linting. I believe in Styleguides. The main purpose of styleguides is this: we have a style guide so that we never need to discuss it again. I once witnessed a centithread argument about whether it should be var == thing or thing == var. Who has time for that kind of nonsense?! Have a style guide, automate it so that Android Studio or XCode apply it automatically, and your code review system shows any deviations – so that your reviewers don’t have to. Code review – done well – is a great collaboration tool. In a dysfunctional environment, it’s the first place conflict will show up. One positive (but insufficient) step towards productive code review is eliminating nonsense arguments about spacing etc.

Tooling on mobile is still behind, but it’s getting better. Things can be a bit more painful to setup, but if you make the time it pays off.

Part of it is having that time. When everything is so frantic, there’s no time to automate painful things to make them less painful.

The anti-pattern of automation is over automation. I’m sure you’ve worked with people – or been that person – who crafts some elaborate system that only they can use to address some minor problem (that only they can see).

Pragmatically with automation, taking the most painful or tedious, hard to socialise parts and making things better is the place to start.

Read the final part, on accountability.