Author: christophertomkochovski

Another topic that has peaked my interest recently and I have started to pay particularly close attention to as I started to really work hard and ensure that I am following best programming practices and reduce any introduction of “code smell” into any code repository that I contribute to, is how to reduce the amount of technical debt a project’s code repository has and to not further increase said debt (sometimes this is not an easy task).

What exactly though is “technical debt”? The definition that Technopedia provides sums it up pretty good in my opinion [1].

“Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”

Some of the causes of technical debt that Wikipedia also provides are also very good and I have worked on projects that have code base’s with technical debt that range from extremely high to very little. Below are several that I personally feel are major contributors when working on projects of any size [2]:

• Insufficient front up design (just take the extra time to think about the implementation, it will help in the long run)
• Business pressures (unavoidable, especially when you have obligations to meet, etc.)
• Tightly coupled components (most likely the cause of bad design to begin with, so design and plan ahead first)
• Lack of a test suite (all too common in most code repositories, test driven development not utilized or unit and integration test harnesses are missing entirely)
• Lack of documentation (again, all too common; not enough time to write up the necessary documentation to not only help you at a later stage but others working on the project too)
• Lack of alignment to standards (sometimes developers feel the need to re-invent the wheel and re-write already publically available libraries, frameworks and APIs causing a major headache down the line)

Now that we have highlighted what technical debt is and some of the causes, it is just as important to try and reduce this technical debt over the lifetime of the project. However sometimes this is just not possible due to a number of uncontrollable factors. Other times however it is squarely in the developer’s hands to reduce as much technical debt as possible while not increasing it as bug fixes, features and improvements are added.

One way that has really helped me is with the use of third party tools and plugins. On most repositories that I work on now, to limit the introduction of “code smell” and ensuring that the technical debt is not increasing, the Git repositories have SonarQube [3] installed on them. Not only does it highlight bad programming practices when there are merge requests but it also analyses the health of the code repository. So there is now no excuse when someone merges in poorly written code when there is an external and impartial tool also looking at the merge request and not just the assignee/assignees who will merge the code; humans can miss some of the obvious things, machines with the correct setup can spot the faults instantly.

Along with the Git code repository monitored, I use a plugin called SonarLint [4] for IntelliJ that highlights poor programming practice and bad code before you even submit your merge request. With the use of this tool, not only does it ensure that I do not contribute to the technical debt, but it encourages me to design, plan and think what I am implementing. Before I was using the plugin, I generally thought that I was writing some good code. However when I started using the plugin it kept flagging my code and letting me know that it was not good code (slightly depressing really); but it taught me that there is still so much more I need to learn to ensure that I write good code. Now that I have been using it for a little while now, I have been getting flagged less and less (so that’s good to know that I am learning and getting better at writing clean code).

Another way that I try and ensure that the technical debt is reduced is whenever I submit a merge request to resolve a bug, or implement a new feature; I try and ensure that the class, method or module that I worked on is in a much better shape than when I found it. Sometimes it will involve doing some light refactoring, other times it will involve re-writing a small chunk of the class or method. However I only ever do this if I know exactly what I am doing, and have experience with the class, method or module. I never try and do this on code that I have very little experience with or don’t know what exactly the code is supposed to do because I could end up leaving the project in an even worse state. People I have talked to about this practice fall into several camps:

1. If you are not directly working on that component don’t touch it. Just do your part and that’s it.
2. Why are you refactoring something if you don’t need to? Leave it someone else will refactor or fix it later.
3. Good show of initiative and desire to clean up the repository, I might end up doing the same. Every little bit helps.

The fantastic thing I have seen is that there are far more developers in camp 3 than in camps 1 and 2. I can see where developers from camp 1 are coming from; making changes to code that directly does not impact your change could pose a great risk, but if you know what it is doing and how to clean up or optimize the code, then why not try and make the repository a little better for all? If there is a TODO or FIX ME comment, then why not fix it while you’re poking around anyway? Camp 2 to me seemed a little odd. Why wait for someone else to fix something if you are already in there fixing or adding something anyway? Could this just be a lazy developer doing the bare minimum? Perhaps. Camp 2 had the least amount of people in it, but I was surprised that was even a response from some developers.

What camp do you fall in? Is there another camp out there? Let me know some of the techniques you use to reduce the technical debt and limit the amount of “code smell”.

[1] – https://www.techopedia.com/definition/27913/technical-debt

[2] – https://en.wikipedia.org/wiki/Technical_debt

[3] – https://www.sonarqube.org/

[4] – http://www.sonarlint.org/intellij/index.html

I have seen many code repositories in my software development life (and I have not really been doing software development very long), and generally see two different types of code repositories:

1. Extensively using public libraries even for the most simple of operations
2. Everything is created from scratch and is managed internally

When I was programming this afternoon and I was looking at a number of code repositories I was wondering; when is it appropriate to use a public library, one that has been tested thoroughly and has potentially hundreds of contributors or do we just write up our own utility classes and methods, making it only available to projects that we work on? It is questions like these that have me stay up late at night, making it hard to go to sleep.

I primarily use Java at work and is one of the programming languages I use when working on my programming projects. Being so popular there are an insane number of super useful libraries out there with a range of purposes. So it is really easy if you are using Maven to manage these libraries and dependencies, and include them for use in your projects. For example, imagine you have the following scenario:

“You want to check whether a String value is null or empty, and this is done in a number of places across the code repository before using this value at any time. ”

The code could look something like this, all over the repository:

String str = getSomeValue();
if (str != null && !("".equals(str))) {
	...
} else {
	...
}

Wouldn’t it be easier to import the Apache Commons package and use the StringUtils class and do this operation instead, having the StringUtils method referenced across the repository?:

String str = getSomeValue();
if (StringUtils.isNotBlank(str)) {
	...
} else {
	...
}

Sure they generally have the same structure and basically offer the same functionality, but I feel the second option is easier to understand and looks better (personal preference).

What I find the oddest though is when you see code repositories that have their own StringUtils class for example that has a method that does exactly this same check as the Apache Commons StringUtils class, just called differently. So we see this instead:

String str = getSomeValue();
if (StringUtils.isNotNullOrBlank(str)) {
	...
} else {
	...
}

Why not just use the Apache Commons class and methods? What benefits are there to writing your own utility classes unless there are specific operations that you need to perform that the public libraries do not offer? Why go out of your way to write your own caching class when you can use the easy to use, extensively tested and heavily documented Google Guava Cache? These are the types of questions I ask myself when I see utility classes that have one or two methods that do the same operation as publically available library class’s methods. Not only do you have to write the near identical code as the publically available class, but you also need to document the class and write up test harnesses for the class to ensure it works as intended. Most of the time the utility classes I see are not documented and/or there are no test harnesses so developers just assume “Yep, it looks like it should work, so we are good to go.“.

Let me know what you generally do when you work on projects. Do you use the publically available libraries whenever you can? Or do you write your own classes and methods even though you know there are the publically available libraries? If you fall into the latter camp, please let me know why. There may be a valid reason that I am just too ignorant or dumb to notice, because generally whenever I have the option I will always use the public library.