Understanding Technical Debt with an Example

By Steve Matthew

Today, I thought I’d explain the concept of Technical Debt, a concept I personally struggled to understand for quite sometime. I used to think that a defect was Technical Debt because I often heard people saying that Technical Debt is a shortcut or a quick and dirty solution. As a result my mind kept associating that to bad quality code and defects because, how could something like that ever meet the Definition of “Done” and be of releasable quality?

After doing a lot of research, asking questions and getting clarifications, what I learnt was that you could create an Increment of releasable quality, that meets the Definition of “Done” and yet incur Technical Debt. Confused? So was I, and I am hoping that through a small code based example I can help make sense of this concept.

So what exactly is this shortcut or the quick and dirty solution that people keep talking about?

Consider the below C# code which takes a random integer between -5 and 5 and then displays the output as “negative” or “non-negative”.

//Example 1:

// The very first time I wrote code looked something like this.

int input = new Random().Next(-5, 5);

string classify;

if (input >= 0)

{

classify = “non-negative”;

}

else

{

classify = “negative”;

}

Console.WriteLine(classify);

========== Output ==========

// When input = 2

non-negative

// When input = -4

negative

Now, consider the below example.

// Example 2:

// After several months of experience and feedback, this is how I would’ve wrote the same code.

int intInput = new Random().Next(-5, 5);

string strClassify;

if (intInput >= 0)

{

strClassify = “non-negative”;

}

else

{

strClassify = “negative”;

}

Console.WriteLine(strClassify);

========== Output ==========

// When input = 2

non-negative

// When input = -4

negative

Notice the differences?

Is the readability much better with the use of indentation? Yes.

Can the type of the variable be easily determined irrespective of where in the code base it may be used or re-used? Yes.

Is the output still the same? Yes.

Now, consider the final example,

// Example 3:

int intInput = new Random().Next(-5, 5);

string strClassify;

strClassify = (intInput >= 0) ? “non-negative” : “negative”;

Console.WriteLine(strClassify);

========== Output ==========

// When input = 2

non-negative

// When input = -4

negative

Notice how the number of lines have been reduced and how the same if-else logic has been represented by a single line of code?

Notice how the output still remains the same across all three examples?

Examples 1 and 2 show how technical debt exists yet the code still works as expected i.e. it is in a “Done” state. Example 3 perhaps is the most efficient way to write the same piece of code, thus reducing/eliminating the Technical Debt because the efficiency is much better when the same functionality can be expressed in lesser lines of code.

This is a very small example of what Technical Debt looks like and should not be used as the only definition, example and occurrence of it. In this small example, the issues that arise with Technical Debt may not be that apparent as this is just a few lines of code. However, imagine a very large code base with thousands of lines of code and similar opportunities for improvement or making the code more efficient. That situation represents the state of the Technical Debt in your code base.

Examples 1 & 2 may be considered “quick and dirty” because it is very easy to quickly write it up, but Example 3 may require some thought, knowledge and experience. It is more polished and has a finesse to it. I’ve heard some expert developers referring to such code as the mark of software craftsmanship.

Have you ever heard your Development Team members complain how there is more work than what they originally estimated when they actually looked into the code base? or that they need to fix something before they can actually start writing new code? Most often, it is something like this that they were previously not aware of that causes their frustration, as the Technical Debt might have accumulated to a very great extent.

What we can summarize from this is the following:

1. Technical Debt is nota Defect. A defect will prevent an Increment from being “Done”
2. The functionality of the developed code does not change as a result of incurring Technical Debt as evident from the examples above i.e. “Done” work could still potentially have Technical Debt.
3. Technical Debt may be intentionally incurred to save time, perhaps to get code into Production faster. In such cases, this should be captured in the Product Backlog and repaid as early as possible. The Product Owner can make a decision after consulting with the Development Team on whether to incur this debt in the first place. Similarly, the Product Owner can make the decision to repay the debt if he/she feels it is economically feasible or necessary for the future stability of the Product.
4. When Technical Debt accumulates, it may become harder to scale and more effort may be needed to reconcile the debt which in turn may affect your velocity to take on new development work.
5. Technical Debt (in my opinion) is not the same as “Undone” work. “Undone” work results from work that was previously considered “Done” but now is longer applicable as the Definition of “Done” gets updated due to experience, new knowledge or new standards.
6. It is best to avoid Technical Debt in the first place. Follow the Lean principle of Build Quality In.
7. Make Technical Debt transparent by adding it to the Product Backlog.
8. If you do incur Technical Debt, let us take a cue from Xtreme Programming and make it a practice to refactor, refactor and refactor!

I hope this was a good read and it helped you understand this concept a little better.

Which Scrum Event Is the Most Important?

By Steve Matthew

“Which Scrum event is the most important? Explain your choice?” is one of those typical interview questions I have experienced from potential peers or hiring managers.

Sometimes, you are even forced to choose one and explain. Sometimes, I hear people saying that the Sprint Retrospective is the most important event because that’s when you get to identify improvements or that is when learning happens. I disagree with this absoluteness and I will be addressing this later in this article.

In my opinion, this is either a trick question or rather a weak one. As a trick question, this gives the interviewer an opportunity to truly assess the candidate’s understanding of the Scrum events, however, if the interviewer, forces a candidate to choose from one of the Scrum events, then it immediately becomes a weak question and exposes the lack of depth and understanding of the interviewer.

I’d like to address this question and state that all Scrum events are important and it wouldn’t be right to single out a particular Scrum event as more important than the other. Each event in Scrum serves a specific purpose and other than the Sprint every event in Scrum is an opportunity to inspect & adapt.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Pay attention to the above excerpt from the Scrum guide. It talks about how the Scrum events enable transparency and as a result of that transparency, provides an opportunity to inspect and adapt.

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Now, let us look at the above excerpt from the Scrum guide. In summary, it talks about how Scrum is founded on empiricism. It also talks about how transparency, inspection, and adaptation are the three pillars of empiricism or empirical process control.

If we tie the information from these two excerpts together, then the understanding is that the four Scrum events (Daily Scrum, Sprint Planning, Sprint Review & Sprint Retrospective) help enable empiricism.

If we look at the definition of empiricism from the above excerpt, then what we can interpret is that the knowledge we gain through experience and what is known can help us learn, improve and even adapt immediately. There is no need to wait.

Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

The above excerpt hopefully strengthens the points I am making so far and here I’d like to address why the Sprint Retrospective should not be singled out as the most important Scrum event.

Please don’t get me wrong, I am not saying that the Sprint Retrospective isn’t important, I am only clarifying that if the reasoning is that learning, innovation, and identification of improvements only happen at the Sprint Retrospective, then that is not a good understanding. In fact, nothing stops a Scrum Team from identifying improvements and improving itself or its process from day 1 of the Sprint. The Sprint Retrospective is the formal opportunity for this to happen, in case it hasn’t already happened.

Thus, my answer to the question “Which Scrum event is the most important?” is: All Scrum events are important as each of them is an opportunity to inspect and adapt, and increase transparency. This will help enable empirical process control. Period.