Every project is different. Every team is unique. Not every process you’ve used on past projects is necessary.
The Outside Looking In blog series is a collection of semi-fictional stories and articles based off my real life experiences and industry observations as a Software Engineer.
Let’s say that I am a truck driver making a delivery and you are the customer. As my customer, you might say that you would like me to drive a particular route. Being an experienced driver I can say “Sure! I’ll drive that route. I’ve driven that way before and know it quite well.”
Since I know the route well I can probably drive it quickly because I won’t need to make so many stops for directions. However, if you don’t trust me enough to drive the route as directed, or you’re not willing to accept small mistakes such as turning one block too early in a residential district then you, being the customer, might set up checkpoints along the way. Such checkpoints will surely increase the likelihood that I reach my destination by the planned route. However, there will be a cost for me to make such stops and check in with whichever systems or representatives you’ve put in place at the checkpoints.
In software, different situations call for different sets of processes. A college professor of mine, who’s research focus was founded in Software Development Process, often began lectures repeating the mantra; “You only Need as much process as you Need”. He would strongly emphasize the word “Need” both times. The idea behind this is that if you haven’t actually identified a concrete need for a process to be implemented within your organization then often it is little more than an efficiency cost to your productivity.
Going back to the truck-driving example. You may have a large team of junior developers that badly need the checkpoints to ensure that software is built to meet requirements. On another project you may have a less-than-mission-critical system being developed by a small team of experienced developers who will by their nature make a best effort to build to requirements, unit test, code review for each other, and check in with the customer to ensure that the system is meeting program needs. Enforcing a layer of checkpoints on such a team may give a paranoid manager some piece of mind but at a potentially high penalty to schedule.
After working in a process heavy environment with lots of checkpoints we can often get trapped into thinking that it’s the only way to work. Let us beware of carrying those assumptions to future projects where they may or may not be prudent. Not to say that circumstances won't ever merit the need for additional process, often-times they do, but let's not institute more processes just because we CAN or we HAVE DONE IT like that before.