Implementing Software without Implementation Debt

So in my last blog post, we talked about various kinds of technical debt. Reckless versus prudent debt, and deliberate versus inadvertent debt. While that blog post was well-received (apple sauce analogies and all), it didn't get too deep. I wish I had written about how technical debt can be avoided during the software development process.

So let's get into that now.

So first, what is Technical Debt?

As a quick refresher, my colleague Paulo Sebastião defines technical debt as: "...the measure of the cost of reworking a solution caused by choosing an easy, yet limited solution."

Makes sense, right? Cut corners today. Pay the price tomorrow. Unfortunately, the price of fixing past mistakes usually costs more money and time than if you just did it right the first time.

Decisions about implementation, architecture, or deployment can all cause technical debt. My colleagues Mike Josephson and Chuck D'Antonio will be discussing architecture and deployment in the next couple of blog posts. To keep this blog post short and sweet, I'll stick to implementation debt or debt that can add up during application development.

What do you mean by Technical Implementation Debt?

We already know that cutting corners creates technical debt. Cutting corners during development (typically code creation) makes technical implementation debt. Preventing implementation debt is easier said than done.

Three simple rules to follow to help avoid Implementation Debt

1. Analyze and Monitor your codebase with the help of software

If you want to keep your code clean and safe, a great way to do that is by using a product that offers Static Code Analysis. Many products provide this. One of my favorites is SonarQube which can even be used in applications created with OutSystems! Another option with OutSystems projects is to use Architecture Dashboard (now AI Mentor System).

AI Mentor System analyzes your OutSystems module and suggests fixes that follow OutSystems’ best practices. Suggestions can include improvements to performance, user experience, architecture, and even warnings of security vulnerabilities. It also alerts you when you have duplicate code, which is great, so you don't have to update the same thing in multiple places. As a former full-time developer of 10 years, finding out that someone wrote the same integration or business logic in numerous parts of a codebase drove me absolutely batty. Duplicate code is the worst. Imagine discovering a major bug, fixing it, but not realizing that the bad code exists in another place!

2. Create code guidelines!

If you have many developers, they may have their favorite way to do the same thing inside their code. As an example, you may have heard of the old programmer debate of "tabs versus spaces." This is just one of many ways that programmers can do one thing two ways, and both are programmatically correct. When all your developers are writing code the same way, they all know what to expect, making the code more easily readable later on.

As a side note regarding tabs versus spaces, I'd like to go on record that I prefer using both simultaneously. Two spaces, followed by a tab, followed by 3 more spaces.

Like        this. 

https://gist.github.com/keithlmurphy/3ea8ee5ebab7ebabf8d2a56af1069d4c

3. TEST! Develop with tests and automate everything!

Creating tests as you develop code is vital for keeping bugs out of your code. Keeping bugs out of your code is key to avoiding having to rework your codebase as more features are added. Essentially this is achieved by creating unit tests to ensure that code does what you expect. What's important here is first making sure tests are small and straightforward, and second (and more critical) making sure that code isn't written without having tests written as well!

What's nice about writing tests like this is they can then be part of an automated testing plan. A simple example is ensuring that every test passes before pushing code from your test environments to production.

If you are looking to create unit tests with OutSystems, consider looking at our BDD Framework and how to automate it in this blog by João Proença.

Final Thoughts

It's easy to say, "this is how you avoid implementation debt." It requires vigilance and nerve to practice these techniques when deadlines are staring you in the face. Sticking to your plan now will save many hours in the future. I can tell you from experience you only need to be working on a preventable bug at 2AM a single time to know how important sticking to the plan is.

Interested in learning more about implementation debt? Join us for an interactive discussion on September 28th with Professor Rick Kazman, author of “Technical Debt in Practice: How to Find It and Fix It.” All attendees will receive a free copy of the book!

As always, thanks                  for reading.