On one of the discussion groups that I’m a member of had a thread that started a discussion on what software development is really after, effectiveness or efficiency. I’ve thought about this over the past couple of days and just decided to dump some thoughts on the matter.
Borrowing Peter Drucker’s definitions for the two words, effectiveness means “doing the right things” and efficiency means “doing things right”. Note that both things are inherently mutually exclusive. If I am driving to work in the wrong direction, I’m being efficient (by driving since by walking I would never get there) but not effective because I’ll never get to work. However, if I take the scenic route to work adding another hour to my commute, then I’m being effective (I will arrive at work) but probably not that efficient. Generally speaking, one always wants to be effective, but being efficient could be considered optional. So if this is the case, which is more important in software development?
I grew up in Nigeria and spent a good portion of my childhood cutting grass and thick foliage with either a cutlass or machete.
It was a highly effective way of cutting the grass as it got the job done. It also left me very hungry afterwards! But I remember having to spend days cutting grass given the size of portions I had. Interestingly enough, on the university campus that I grew up on, the landscaping team also used cutlasses to the cut the grass of all the fields on campus. It would take days for them to complete, and areas like our football (soccer for my American friends) fields would be last on the list causing us to go weeks without playing at times. For those who know me well, you definitely realize how tragic this must have been for me.
Then the university made an investment in riding movers and all of a sudden, it no longer took weeks to cut the grass, it was all done in a matter days. The university leadership realized that even though the right thing was being done (effectiveness), it wasn’t being done in the right way (efficient) given the size of the campus. Introducing riding mowers allowed the grass to be cut quickly and consistently, improving the overall aesthetics and beauty of the campus. It also opened up the doors for the landscaping team to do other things besides just cut grass! Most importantly, it allowed yours truly to play football whenever I wanted to because the fields were always in tip-top shape. The landscaping team was now both effective and efficient.
It’s easy to understand why being effective is important – we all want to do the right thing and I would suggest that a lot of our energies go towards effectiveness (especially when agile practices are employed). It’s much easier to see ineffectiveness. Your “customer” will tell you. Efficiency on the other hand can be a little more subtle – it’s harder to see, harder to challenge and harder to understand. If things are working (effective), in my experience, efficiency takes a back seat. The classic “if it ain’t broke why fix it ?” approach to things. Yet, efficiency allows us to scale our operations providing us with the opportunity to do other things including living more fulfilling lives! We are inherently making our company more profitable because we are possibly getting more done in the same amount of time as before. Remember, time is money. For example, manually executing a hundreds of test cases may be very effective but is probably inefficient and so to improve efficiency, we decide to automate tests allowing testes to focus on exploratory scenarios or help with requirements gathering. We don’t need cross-functional teams to be effective. We introduce cross-functional teams because makes all the roles/functions needed to deliver solutions readily available to us. It reduces communications challenges and allows us to respond to each other in minutes instead of days. It improves the overall efficiency of the team. The same is true for co-located teams. That being said, it’s important to note that improving efficiency can also be an expensive undertaking. It’s important to a have “sense” or “feel” for what the gain in efficiency is really going to provide and what the objectives are.
Is it okay to be inefficient in order to be effective? Sure. I’m familiar with at least two cases (I imagine there are others) such as having multiple people on a team researching a critical production issue or not having members on the team with siloed responsibilities such as “application developer”, “database developer” or “UI developer”. We’ve given up some efficiency in order to be effective by allowing everyone to do some UI development for example.
We should understand that in figuring out the “unknown” as we often do in software development, we will not be as efficient as we could be if we knew exactly what we were doing. (Think about all the hallway discussions that occur or the back and forth that we end up realizing was not necessary after the fact). We are conducting a bunch of experiments, coming up with new recipes. That being said, it’s not an excuse to accept inefficiency as the status quo. Practices such as TDD, using user stories to gather requirements and just-in-time planning, using dynamic languages to name a few, provide efficient approaches to working with uncertainty and vagueness.
Let me suggest that both effectiveness and efficiency are equally important in software development (except when what is being developed and delivered is of little consequence – why are you working there?) and software teams should focus on continuous improvement in both areas.
Photo of my very own cutlass
Riding Mower photo from Jeff Harbert