Three types of technical debt and how to avoid them

 

Three types of technical debt and how to avoid them

If you are currently working with a software development firm or are considering hiring a firm to design, develop and implement software, familiarize yourself with the following so you don’t get into technical debt.

“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.” (Techopedia.com)

Example 1:  Your programmers knock out some code and they give you a demo. Wowee! It’s great; let’s go to production. You get to production and it crashes. What happened? you ask. 

Well, those programmers were using a small amount of test data when they gave you that demo. Of course, it worked great and was super-fast. But, not really. Instead of architecting it for high-performance from the beginning, they made it look pretty for the demo. Got you all excited and then let you down hard. Now you are in technical debt.

How to avoid it: 

  • Plan for performance from the beginning.

  • Get yourself some test data; lots of it.

  • Don’t go for “quick and dirty” solutions that are woefully inefficient. 

Example 2: Your programmers allow a backlog build-up of bugs and repeatedly say, “yeah, we’ll fix those later.” And you know when later comes? Either when you’re pushing the new code to production or more embarrassing for you, when you are giving a demo to your boss, or even worse, never. 

How to avoid it:

  • Familiarize yourself with your bug tracking system. Keep track of the “cosmetic” defects count and don’t let it get too high. If your list of “we’ll fix those later” bugs gets beyond 50, you’re going to end up with a sprint or several of doing nothing but fixing stuff that should have been fixed a long time ago. 

  • When it comes to “cosmetics” they are usually misspelled words or incorrect grammar. Have someone other than the developer read the screen and provide quick feedback to the developers when “cosmetics” are spotted.

  • Run the spell checker on all UI components and don’t even create a bug in your tracking system for misspelled words. Fix it now!

  • Ask developers to copy and paste text that is written by subject matter experts. Rekeying text by developers almost always results in “cosmetic issues.”

  • Add several bug fixes to each future sprint.

Example 3: NOT putting in security features up front. That is like building a house and putting up the drywall, painting and then installing the electrical wiring. Yes, what a mess and $$$ costly.

How to avoid it:

  • Create your security requirements first and design for security up front.

  • At a minimum have security rules for: 

    • Credentials

    • Authentication

    • Authorization

    • Session management

    • Source code

    • Data

    • Services

    • Logging.

And ... what other areas can you think of? Here you will find a great resource https://fluidattacks.com/web/products/rules/ 

Agile is good; technical debt is bad.

We practice good agile. This enables us to get a velocity going that leads to efficient decision making. We use Jira to track all our requirements and bugs. And our PMs keep a keen eye on Jira and the actual software applications. Yes, every software system has bugs, even ours. But we catch them and if we don’t catch them in unit testing then QA does and reminds us that we aren’t super heroes. In any event, we don’t like debt and especially not technical debt.

 
Kathy BakshyComment