The biggest pushback I got for my Seven Signs of Dysfunctional Engineering Teams post was in response to my point that dysfunctional teams favor process over tools. They argue that it’s easier to change a process as opposed to a tool, and that the more important distinction is in creating a “good process” rather than a “bad process.”
Creating processes is the default in any organization. Creating process starts out simply by reminding people of things, “Make sure you turn out the lights before you leave the room.” Or, “Please email the international team before you launch any features on the UK site.” The establishment of new processes is normal and completely expected.
Atul Gawande became famous for writing about how process can save lives, talking about how discovering best practices and codifying them can provide massive benefits in a medical setting. The New York Times published a really interesting article about Toyota donating efficiency to the Food Bank for New York City. Process improvement is great, and useful.
However, as engineers working in the world of software, we should be building tools to automate these processes whenever it makes sense. Why write down a checklist if you can write a script to execute it? By building tools we can make doing the right thing the path of least resistance. Automation is no panacea, but it can be a powerful productivity multiplier, especially for managers.
Here’s an example. I worked at a company that had a large set of regression tests that were run before every release, and no automated testing regime. When we were ready to release, the entire product team spent at least a day reading tests in from an Excel spreadsheet and running them against the system. Running them by hand created the opportunity for humans to notice problems that may have been beyond the checks in automated tests. On the other hand, this process was incredibly slow, and had the effect of creating a serious disincentive for pushing new releases, which was a problem unto itself.
The sign of dysfunction I was talking about was that an organization fails to recognize and exploit opportunities to create or obtain tools to replace processes or automate redundant tasks. This can happen for a lot of reasons, but the most pernicious is an unwillingness on the part of management to invest resources in building internal software.
That’s what I was talking about.
A blog is a relationship
I am in the process of writing a post about Ta-Nehisi Coates’ blog that I was going to share with some friends who don’t read it. I started thinking about points he’d made that I wanted to include, and tried to find the posts where he made those points by way of Google. Then I started going through his old posts page by page, and I realized that the whole is far more than the sum of the parts. He’s written some great sentences, and great paragraphs, and great posts, but the blog is a body of work that reinforces, illuminates, and colors the parts that one might want to pick out and share. This may be the first time I’ve had a real sense that blogs really are a new form of writing, different than even a regular column. People may appreciate the posts I select, but they won’t have the same relationship I have with the writing, having read it as it was published over a number of years.