We’ve all seen the commercial. A prototypical person moves into their very first home. We watch as they excitedly place a third box into a room, only otherwise occupied with a bean bag and floor lamp. They place their hands on their hips, look around with a smile and close the front door. It’s an exciting start that logically is followed by the purchase of furnishings and décor to make the house a home. Building an application or service is much the same; developers start with a seemingly blank slate and countless opportunities to create an appealing product.
Fast forward a few years and our typical home buyer is now reluctant to purchase anything new because they have filled their house. Where would they even put it? Yet, they don’t want to get rid of items, thinking they may need it later or, they’re simply attached emotionally.
Applications, like the full house, can similarly suffer. As developers add more features and functionality, the code base swells, and developers may choose to not add a new feature due to the existing code volume. Developers also experience concerns about reducing code fearing they may remove a feature that customers really like or they, too, may be emotionally attached to their past work. And, to be honest, when is the last time someone was applauded at an all-hands meeting for removing code?
Introducing continuous abandonment
Stop the cycle of code bloat with a culture of continuous abandonment. This intentional removal of code makes room for innovation, speeds delivery cycles and helps avoid the collection of technical debt. While you don’t have to give a trophy to every engineer that removes a line of code, we do advocate that developers build continuous abandonment into their processes. For example, if a new technological advance is introduced that subsumes an existing feature, that feature is ripe for removal. In addition, by regularly assessing code to abandon at a pre-defined point in the development process, developers can avoid the equivalent of your home’s spring cleaning.
The continuous abandonment cycle is even more effective when paired with cloud-native development approaches. Consider: in monolithic applications, it can be that the initial developer is long gone, and it’s a mystery what would happen if code were removed; no one wants to play a game of Jenga with a monolithic application and therefore it becomes easier to let it be, rather than risk adding or removing too much from it.
Conversely, cloud-native development offers several benefits that encourage continuous abandonment.
- Microservices have fewer dependencies and therefore it’s easier to remove code without fearing repercussions. Additionally, their autonomous nature makes it easy to remove an entire service without negatively impacting other parts of the application.
- Breaking a larger application into microservices also allows teams to focus on specific services and functionality, giving them more intimate knowledge of code. This in turn makes it easier for developers to identify code that should be retained and code that should be abandoned.
- Cloud-native development encourages experimentation that can lead to innovation. With the ability to easily remove code that is a failed experiment, developers can try new things with less risk. Should the experiment be a success and deemed worthy of adding to production services, developers should assess which, if any code, should be abandoned in response, answering questions like, ‘Does the new code supersede existing code?’ and ‘Does the new code make old code obsolete?’
Realtors tell homeowners that they should regularly update their home, making sure it’s well maintained. Issues ignored can turn into costly projects. Similarly, organizations that ignore code bloat for too long can find themselves unable to effectively update, maintain, or add new features to their application because it’s become too unwieldy to keep up with. When market parity can no longer be maintained for these reasons, customers become dissatisfied.
Continuous code abandonment is a cycle to proactively ensure that applications and services retain only that code that makes then market competitive. It enables organizations to experiment more, grow innovation and remove technical debt that slows business growth. So, whether you are embarking on a new application or service, or are looking to modernize a legacy application, now is the time to introduce the rigor of regularly assessing code for continuous abandonment.
Read more about continuous application abandonment in our VentureBeat article.
Post Date: 08/19/2021