Changing the way a large organization does things can be a challenge. Even the smallest change can invoke the infamous “if it ain’t broke, don’t fix it” reaction. But as we will show, even a minor change in the way our customers wrote their software resulted in tangible, long-term benefits through low-risk innovation. If you think that nobody cares if your source code is formatted consistently, or your methods and variables are named per standard, and that code style is just not worth the hassle – our results show otherwise.
Most of us have some negative memory about innovation from the past, like buying up a bunch of HD DVD’s only to see them become obsolete when Blu-ray emerged as the winner in that space (https://en.wikipedia.org/wiki/High-definition_optical_disc_format_war). On the flip side, we know that if we don’t consistently keep our software development process up to date and stick to the “that’s the way we’ve always done it” mentality, our competitors will eventually render us obsolete. As such, we need to find a balance between the two extremes. In order to stay ahead of the curve and minimize risk, we can follow a controlled change management paradigm to successfully implement low-risk innovation.
Low-Risk Innovation
In this article, we will cover a low-risk change in the software development process – implementing a code style policy. Such a change is a great way to push innovation further; the risks are low, but the rewards are real and provide a baseline for further improvements.
Java Code Style Initiative
The development team undergoes several organization-level transformations, managers move to different teams, and the like; at the end, a new head of development emerges. The leader has a deep Java-development background. She can fire up IntelliJ or Eclipse as well as anyone in the development team. During her first few weeks, she sees that the source code for the project does not have a consistent coding style. The leader wants to propose the idea of instituting a code style policy for the project. However, she has to first consider all the what-if’s and gotcha’s which can wreak havoc on a new initiative very quickly.
Having used Google’s Checkstyle (https://github.com/google/styleguide) policy before, but only with the IntelliJ IDE, she sets up Eclipse on her workstation and confirms that Eclipse does indeed support it. Imagine how it would look if all the wheels were in motion and it would later be discovered that one of the required IDEs does not support the tool!
Bring the Idea Forward
Based on past projects and current industry best practices, the leader knows that code compliance is a clear win. It is low-risk and has tangible benefits. She meets with the business to propose the idea. She presents several case studies showing how using Google’s Checkstyle policy resulted in higher developer throughput and less software defects. For risk mitigation, the leader explains that because all of the source code is already versioned, the code can always be rolled back to the original state. After the project’s timelines, resources, and budget were evaluated, a pilot program for a low-risk module is approved. Thereafter, the leader speaks with the pilot team and their scrum master about next steps, and progress begins.
Pilot
After several sprints go by, code refactoring had begun, and DevOps implements the Maven Checkstyle plugin in the build. This plugin monitors the refactoring progress. The pilot team provides feedback to the head of development. They are concerned that some of the rules in the policy are too pedantic and non-beneficial. After some follow-up discussion, the plan is to refine the code style policy.
The development team becomes more confident about their code style progress. Thereafter, DevOps updates the Maven Checkstyle plugin to fail the build unless it satisfies a threshold of compliance. This threshold is further adjusted after too many failed builds and followup discussions. Going forward, the threshold for code style will be gradually increase over the next 5 sprints. This will ensure that the pilot development team can continue to concentrate on the core business development tasks, but still bring code style compliance to 100% completion.
Success and Next Steps
Fast forward 5 sprints, on a team-wide demo, the pilot team demos a 100% code style compliant Jenkins build. The scrum master presents data showing that because of code style compliance, there were less software defects than before. Furthermore, developers have expressed their positive feedback with the policy. It makes the source code easier to understand, reduces complexity and increases development throughput. Based on feedback from the developers to the team leads across the different project teams attending the demo, the consensus is to implement a code style policy across the whole project.
The code style policy, refactoring process and enforcement policy are now established. By leveraging these proven processes, instituting code policy for the rest of organization will be that much easier.
End-To-End Plan
Here is how a code style implementation transpired from an idea to an organization-wide software development policy.
