I was reading the “Writing and Shipping Code Faster” section of the 2021 State of the Octoverse. The report includes a diagram that indicates predictive relationships between software development practices and their impact (both positive and negative) on the organization’s ability to deliver code.
One thing that caught my eye is that in the “work” context (as opposed to the study’s separate findings about open source communities), the practice of “easy to reuse code” was positively correlated with the perception of being “empowered to work.” However, “code designed for reuse” had a negative relationship with empowerment.
The difference between reusing code vs. designing code for reuse felt worthy of reflection, so I dug into the survey questions. For each question respondents could choose between Never, Rarely, Sometimes, Often, and Always. The questions for each concept were as follows:
Easy to Reuse Code
- I would like to use or continue to use code or libraries from outside my team or repository
- I currently use code or libraries from outside my team or repository
Code Designed for Reuse
- Accept pull requests from people outside the project or team
- Respond to pull requests or issues from people outside the project or team quickly
- Describe whether the code will be supported in the future
- Design documentation to make dependencies clear
- Write comments that describe how each part of the code work
- Modularize code so that people can reuse individual
In short, it appears respondents are interested in the efficiencies of reusing other people’s well-documented, well-supported code but feel less productive and empowered when doing the work to make their own code similarly reusable for others.
All of which is the say, the distinction between easy to reuse code and designing code for reuse reminds me of my all time favorite Onion headline.
No Comments