“Always Remove Orange Cords”
Recently I came across the following interview with Chief Product Officer Gijo Mathew at VTS. In this interview, Gijo brings up a principle of his that he calls “Always Remove Orange Cords”. Gijo tells an anecdote of an orange extension cord that one day appears in the company’s office lobby. No one seems to care about this random extension cord, until someone new walks into the building one day and follows it only to find out it isn’t plugged into anything and serves no purpose. Gijo then goes on to say how he looks for “orange cords” in his companies, especially when first starting to remove old and outdated processes that no longer make sense or are useless.
Always Follow Orange Cords
Gijo’s principle made a lot of sense to me and made me quickly think about how it can be applied to software development. However, I don’t think it’s always necessary to remove “orange cords” though. However, I think it’s very important to always follow “orange cords” and trace it back to the source so that you can understand its purpose and why it’s there. Only then can you know it’s use and whether or not its purpose is still necessary. I believe that following “orange cords” will not only make you a better engineer but also greatly benefit your company as a whole and setup future engineers for success. If you and other members of your team are actively searching out and removing unnecessary things it will keep things cleaner and more maintainable. Orange cords can come in all shapes and sizes, so it’s important to not think anything is too big or too small to possibly be unnecessary and removed. Let’s look at a few different examples of “orange cords” you can come across in software development that need to be removed.
Lines of Code
The first type of “orange cords” I want to discuss are as simple as a single line of code. Over time lines of code can easily become deprecated or useless. Functions change and functionality changes as new features are developed. A common example can occur when handling errors or one off cases like in defensive programming. Maybe there is some function you call that occasionally raises an error. Then at some point the underlying error is fixed or handled within the function yet your original code remains unchanged. This can lead to unnecessary code that stays around after it is no longer needed and confuses developers or gives them false information about what can occur from the underlying function.
Another example of lines of code that can become obsolete or unnecessary are if/case statements, especially ones involving other function or API calls. You may have if/case statements to handle an API’s response in certain cases. This can become especially common when there are different versions of API’s or in the process of updating an API. However, after a bit of time all cases may fall into one singular case and the if/case statement may become obsolete. It is necessary to keep track of these and remove the unnecessary statements, which will simplify your code.
One final example I want to think about for lines of code that represent orange cords are feature flags or a/b tests. It is common for organizations to use feature flags to quickly turn on and off features for users or to use a/b tests to turn on and off features/experiments for cohorts of users. This is an important task of data driven organizations who want to test things quickly and be able to rollback changes quickly. However, organizations will eventually come to a conclusion on one solution at some point making the feature flag or a/b test code unnecessary. The organization will generally hardcode the final solution and remove the feature flag or the other experiment. Nevertheless there are times I’ve encountered where this step is forgotten, for any number of reasons, and the feature flag or a/b test mechanisms are relied on to make sure all users have the same experience. This can be avoided though by recognizing when a feature flag or a/b experiment’s time has ended and removing the unnecessary code that is no longer needed.
Functions or Modules
Functions, methods, modules or whatever your language decides to call them are incredibly useful and necessary in production code bases. Without going into too much detail why these abstractions are necessary, some reasons for abstractions like these are organization, reusability, ease of testing, and extensibility but you can read more about this here. Nevertheless, these too can become unnecessary orange cords that need to be removed from your codebase at some point when they are no longer being used.
It is quite common to need functions at one point but at some point have the functionality change or add the same functionality to another abstraction that will handle it from now on. In these cases your old function is no longer necessary but sometimes it remains around in the codebase. I’ve seen many developers wary of removing code old code just in case things need to be reverted. In these cases we leave around this extra function instead of deleting it and future developers gloss over it thinking it is important for some reason or another or maybe used in a place they aren’t touching. It is important to delete code as soon as it becomes unnecessary and is no longer in use because it becomes increasingly less likely it will happen as time goes on. Other developers will be less inclined to remove it unless they take the proper time to get the proper context and remove it.
Files
Files and all the code within them can become orange cords very easily. I saw this very common orange cord in a frontend codebase. There were dozens of old components in their files that had become obsolete over the years as new components with new functionality or designs were created, or as old features were removed. It was especially confusing when many of the files had the same names but existed in different directories or had very similar names. It became increasingly harder to find the correct and current version of the component. A simple change in the design could take hours instead of minutes when coming to a company that hadn’t been touched in a while, because you had to search for the correct and current version. Nevertheless, this is not just something that can happen in frontend codebases but in any codebase. As development continues in any codebase, it is common for old classes or services within files to be replaced by newer ones or have their functionality removed entirely. This can lead to the code within a file never being used in the codebase again, but it was left there by someone unsure of when or how to remove it. It is important for code to be deleted from a codebase once it is obsolete. As I outlined it can make your job as a developer more difficult when there are a bunch of unused files remaining in a project and you unnecessarily search through them. Also, allowing old unused files to remain in a codebase can increase the size of the overall application which although at first may not be an issue, it can become a problem down the line when the size of the application matters. This is especially true for frontend applications. Remember if you are using version control it is always possible to revert changes or look back in history to find code that has been removed and put it back.
Applications and Systems
The next level of orange cords and last I’ll discuss are applications or entire systems. There is a common theme here of things that become obsolete and forgotten but I want to highlight even apps and systems can become orange cords. Sometimes apps are replaced by newer versions or broken into microservices and monoliths become unused. Then there’s the case that even entire systems can be replaced by new systems. An example might be a logging system that gets replaced by a newer, faster more robust logging system. Or another example is a third party system that is brought in house or vice versa, and sometimes it can be forgotten to delete the unused system. This can become a problem especially when using both systems for some time before fully transitioning to the new one. Still, in extraordinary cases maybe a system becomes completely obsolete without even realizing it, hopefully this is never the case, but here especially you may find yourself with an orange cord that is never used without knowing it.
Conclusion
With all of these examples it is easy to see why I liken them to orange extension cords that are unplugged and can be removed. As time goes on and no one removes it, it will eventually come up to one developer to take time to properly follow the orange extension cord to its source and see that is is no longer in use and can be removed. However, the longer the extension cord goes unfollowed the longer the cord will become because it’s history and time in general goes on. More and more commits and documents will have to be traversed to get to the beginning of time when it was created and when it became obsolete. Nevertheless, this is an important job and something good developers should take the time to do. Not only will it clean up your code base and your systems, but it will also make your fellow developers lives easier. There’s also some cases where it can save you or your company money in more ways than one. Hopefully looking at all these different examples have shown you that orange cords can come in all shapes and sizes and therefore you should always be on the lookout for them. You should strive to always take the time to understand every bit of code, every function, every file, app, system, etc. that you come across and what it’s purpose is. You will have to put more time into your initial feature development to understand everything around you, but as time goes on this will actually save you time because you will have to do less searching. The initial upfront work you will do will make you a faster and better developer, able to easily jump into a project or feature request because you don’t need to spend as much initial investigation for each one. Hopefully this guide will help you identify orange cords that can be removed, make yourself a better contributor, and help out your teammates and future teammates. Remember to always follow orange cords please!