Hidden Costs Of Striving to Maximize Productivity
Cost of Measuring only What Is Easily Quantified.
I work as a software engineer. My job entails converting business requirements into code accessible on World Wide Web. For majority of my work make changes in the existing code to create new features. This is not as straightforward as writing code from the scratch. Sometimes mistakes are made, existing features break, customers get upset, company looses revenue and developer gets fired. Sometimes.
All software development shops and almost all developers aim to add new revenue generating features without breaking existing features already generating dollars.
This goal leads to four possible scenarios enumerated below:
We are told that success is better than failure. And two success is definitely better than two failures. With that simple maths scenario #1 is the most preferred objective of software developers.
This success/failure metrics is often employed for performance evaluation because it is a very visible and easy to measure.
Regrettably , what can not be measured easily is often ignored or left at the discretion of developers.
In software development adding new code has impact on the structural integrity of existing code. For example, addition of a floor to a building, if not done the right way, makes it weaker. But, if the new floor is added with thorough consideration to the impact on existing structure it may have minimal or no impact.
Same way adding new code to existing code, if not done by following the established standards and practices can make the foundation code harder to work with. In the longer term this can lead to a fragile product with lots of features.
The cleanliness of code and its adherence to established standards is not a metrics often measured. Since it is not measured a developer is not rewarded for the extra effort to write clean code; neither she is chastised for writing messy code.
At my job I have often aimed for approach #1 (two success) because doing anything different has potential of failure (approach 2, 3 or 4).
This emphasis on focusing on success so no bugs are introduced actually generates nefarious and harder to troubleshoot defects.
The pros and cons of two approaches are:
The table sums up the hidden cost of focus on short term productivity. It blinds us to the longer term costs.
Productivity is about end results and getting things done. But in the rush to get things done we sometimes takes the fastest and safest path with repercussion of the overall health of the system.
In a software company emphasis on productivity may make underlying platform more fragile and harder to work with. A restaurant with a priority to provide fast service may serve excessively processed food. A farm with focus on getting the maximum yield per acre might use high amount of fertilizer and pesticide making land more dependent on chemicals.
This week I decided to be take the road less travelled — I focussed on quality and not productivity. I spent a day testing ways to keep the foundation code unspoiled as I coded the features assigned to me.
Sometimes the merging of these two approaches is not very straightforward as I learnt to my dismay. After many attempts I could not come up with a satisfactory solution. I decided to revert my changes, turn back, and take the road that I knew would take me to my destination with certainty.
I was a day behind, it was a day well spent. Even though I did not develop any new code, my ability to take initiative and risk developed.
I took initiative by merging unstated but important goals with the goals stated in the business requirement document.
I risked missing the deadline by trying a potentially less productive but more holistic approach.
Now that I am utilizing the approach I decried initially (focus only on developing new features) I am doing it with the knowing that I gave the more holistic approach (focus on keeping the underlying code clean along with developing new features) my sincere attempt.
It sounds paradoxical but even though nothing has changed everything has changed. I feel a new level of investment and engagement at my current. And this is sufficient to make up for loss of productivity incurred with taking initiative and risk.