Skip to main content

Process vs. People

dish washing

I do not have a dishwasher in my kitchen. When washing dishes by hand (and choosing when to wash them), the real objective is to minimize the amount of time dirty dishes spend in the sink. So the right process, would simply be to wash dishes as soon as they are used. Like most good programmers, I'm quite lazy, and stop following this process within a day or two. I then revert to the process of necessity, which is to wash dishes right before they are needed, which works well for frequently used dishes, but poorly for the ones that are used once a month. So the process that I've found to work the best, is when I need to wash dishes that are about to be used, I wash at least some of the infrequently used ones (like I said, I'm lazy).

So it turns out the best process for washing dishes for me, is not the "optimal process". The same is true for software development. When developing software, the most important thing is the people: the customers and developers. Your processes need to fit them. Its too often we see the rules of scrum or other practices rigidly enforced, software developers evaluated on how well they conform to certain processes, and tools chosen independent of the developers who will use them.

Rigidly Agile

Its easy to be convinced that processes are all that matter. Sometimes you find yourself on that team of very willing people, and you implement every process you want. Development goes awesomely, you review code, everything is documented and united tested, and do regular agile ceremonies (planning, retrospectives, etc.). But the real reason the software project goes so well, is not the process used, but a team using the processes and tools they love.

Go to any software engineering meet-up, and you'll hear about someone trying to fit the wrong process to a team: "I can't get my developers to write unit tests.", "No one will do code reviews.", or "Everyone commits undocumented functions.". Now, I'm a big believer in unit tests, code reviews, and documentation, but these things are only constructive for a team that believes in them.

We want to build software that is flexible and non-rigid. Software that we can easily modify, reuse, and re-purpose. So why would we want to take such a rigid view of the process used to create the software? Why are the rules of Scrum treated as unbreakable? Having a scrum-master who is also the product manager in most cases works just fine (especially if they are a reasonable person). Even not having a scrum master can work too (or a product manager for that matter). Having stand-ups every other day instead of every day may improve team communication, as members won't wait to talk until stand-up.

Why does software development tend toward rigid processes? Because rigidity is easy. Software developers are used to programming computers, so if you can define the process with if statements and assertions, it just seems natural. Senior management likes rigid processes, as from their perspective it eliminates risk. If you give your software developers specific unambiguous instructions on how to get things done, thing should get done in a reliable fashion right?

Individuals and interactions over process and tools. - 1st value of the Agile Manifesto

But the truth is specific processes and instructions are great for computers, but terrible for humans. Humans are bad at following exact instructions. Humans are good being creative, solving problems, and making decisions based on undefined data. So why would you want to force people to do the things they are weak at, and not let them do the things they are strong at? Especially since hiring programmers is one of the hardest parts of running a software team, why do things which make it more likely for your programmers to leave?

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. - 5th principle of the Agile Manifest

How do you motivate individuals? Make them feel important. Give them freedom, and base the software development around them. You need to change your process to fit your team. Over time, your team will change, and subsequently the processes that best fit them will too.

Some languages are more equivalent than others

animal farm

This is why, after writing two web applications in it, I have stopped using Go for new development. Go compiles to native binaries, has static typing, memory management, implicit interfaces, and solid web components in its standard library. However, the tools for the language seem to designed with the idea that there is only one way to do things. If you use the go binary to compile your project, you must not only structure your project in specific way, but you must structure your whole development environment a certain way. While the formatting tool used to allow some customization (i.e., spaces versus tabs), this functionality was removed. While in theory someone could make flexible tools for Go, no one has yet, and the Go community seems to discourage such development.

So I've reverted to using Python for web development. It uses duck-typing, is interpreted (i.e., significantly more overhead), and CPython enforces a global interpreter lock preventing multi-threading (at least in any sane way). But, Python and its associated tools allow for easily favoring people over process. The wonderful tool Pylint allows for complete customization. Even autopep8 which is for formatting python code to be PEP8 compliant, can be customized to format your code in a non-PEP8 way. The bottom line is, you can python development can easily be adapted to fit a team, where as Go really requires the team to adapt.

I'm not saying teams should not use Go. Go is a great language with great tools. But it should only be used by teams for which those tools are a good fit, and unfortunately due to the rigidity of its tools, the number of those teams is smaller that it could be.

Change is good.

Developing software on a team is hard. That's why we do things like sprint retrospectives and reviews. Because we want to change the process so that it works better for our team as often as possible, and as the team changes, the processes change with it. We want the members of our team to be happy, and to be an important part of making technical decisions. We want to use tools that change with our team and our processes. Agile software development is not the use of Scrum, Kanban, or Extreme programming. It is the application of such things WHERE and WHEN they make sense. It is about making customers and developers happy.