Code entropy
During a recent meeting, I was asked a question that I have never been asked before using this terminology, but one that piqued my engineering mind and one that has tremendous implications for you and your business depending on how you answer it and whether you are intentionally doing something to solve for it or not. How do you deal with code entropy?
Anyone who has been working with developing software for a while has experienced this phenomenon, knowingly or not. You start on a new, green field project and spend time thinking through how to structure the code; how to break apart the problem space into modules, assemblies and components; how variables, methods and classes should be named and their individual and collective functions within the larger system; where model and business logic should reside and how the UI should interact with the model and underlying business logic. You launch into development with a mission to build a great piece of software, the right way, without the shortcuts or poor code quality you have experienced time and again in "legacy" systems. The project kicks off and everything is coming together the way you expected, code is organized and makes sense, things are great. Then something irreversible happens, the first release of the application occurs. From that point on (and most likely earlier) you are battling against code entropy.
Code entropy, or the tendency of source code to gradually become disorganized and difficult to maintain, is similar to the second law of thermodynamics from which the term entropy is most commonly associated, in which systems naturally trend toward a state of disorder over time. This phenomenon occurs as code is updated, enhanced and modified to meet changing business requirements, resolve defects or provide new capabilities to satisfy user requirements. These changes are often performed by different engineers at different, often distant, times in the software development life cycle of the application and result in code duplication, different naming and code standards being used, blurring the lines separating responsibilities of components and a general lack of code coherence. So how do you combat code entropy and keep your code base from drifting into anarchy?
My answer is simple; collective code ownership. Extreme Programming espouses this concept and I've become an ardent believer and proponent of this software engineering practice in software engineering teams I have been part of and lead, regardless of if the team is using Extreme Programming or not. Too often, I have been part of or managed software engineering teams where one person is the lone keeper of a piece of code, module, assembly or on the extreme end of the spectrum, the entire application, in a strong ownership code ownership situation. In my experience, this weakens the agility and effectiveness of the team and can greatly impact the speed at which changes to the code base can be made and propagated to the business and ultimately the customer. This is also a significant vector to induce code entropy into the code base as engineers leave the team and new engineers take over.
Collective code ownership empowers and encourages anyone on the team to make changes to any section or piece of code. This requires a lot of collaboration and care with how code changes are introduced into the code base to ensure that high code quality and cohesion are maintained. In my experience this is accomplished through the use of three simple, yet often poorly (or not at all) implemented software engineering best practices; published code standards, unit tests and code reviews. These three software engineering best practices are worthy of implementing in their own right, but when combined together, naturally lead a team into a dynamic of collective code ownership. I will write more about my experiences implementing each of these practices in future articles, but for now I'm going to leave this right here. I look forward to hearing feedback from my peers with your answer to this question and experience mitigating code entropy.
All the best, Cory-
https://www.agilealliance.org/glossary/collective-ownership/
http://martinfowler.com/bliki/CodeOwnership.html
We keep and maintain a dev backlog. We are an agency, so our code entropy needs are different. There's usually a big effort every year to go through our code and do updates/cleanups. We've also created standards guides in the past couple years to help people know how to write good code and we've adopted practices like BEM to help with our naming conventions. We take a lot of approaches to this problem, but none of them solve it. Just mitigation strategies, I suppose. Thanks for this post!
Hi Cory, Interesting and valuable article. I'd be interested in hearing about what changes you have made to your practices to fight code entropy that "stuck," and are now part of your regular coding regime. Regarding part of your definition of code entropy that states "the tendency of source code to gradually become disorganized and difficult to maintain," My mind goes back to starting with well defined and documented requirements at the beginning of your project. Then all future development has to be integrated into those initial requirements, helping to ensure proper integration of new requirements. So I know that I'm stating the obvious; you can't properly test code that doesn't have thorough and accurate requirements, users statements, ....... And Hi to Leslie, too. I trust that all is well with you and the work you are doing. My way of dealing with the situation you describe would be to have a clearly-stated requirement in the chief architects performance plan that states something to the effect of: Objective x.x: Ensure that other developers receive the proper mentoring and training so that they can can perform at least two (or whatever number is appropriate) full code reviews on x number of pieces of code that are checked into your build repository. It's a reasonable request that will potentially hit them where it hurts; their compensation. So cheers to all, and I hope things are going well. Phillip Hazur
We followed these operations religiously in my software team and they paid off exactly as advertised. It requires not only diligence but also top notch programming talent and cultivating a certain humility on the team so they can collaborate well. But it does work. The biggest challenge I encountered was with my chief architect who insisted on reviewing all code himself regardless of who else had reviewed it. I was never able to teach him how to pay his review skills forward rather than just review himself. If you have suggestions on that score I would love to hear them.
Interesting Read.