Is your team and software development heading towards knowledge debt? Outdated methods can harm your business, and different companies and projects experience knowledge debt in different ways. By identifying exactly how knowledge debt could be impacting your business, you can then take the first steps towards reducing it, and continue to empower your team so that your engineers can become better leaders.

What is Knowledge Debt?

Knowledge debt refers to an unawareness of new information and developments within various fields of expertise, which accumulate to form knowledge gaps. This applies to both a team’s skill set, and, in the case of software development, the technical debt which results from outdated technology. Knowledge debt in software development is therefore often referred to as "technical debt."

While knowledge debt may not prevent you from operating your business or from continuing to design products, but the knowledge gaps which accumulate as a result can hinder progress in a rapidly evolving industry.

Luckily, the information and training needed to reduce knowledge dept is readily available and discover-able. Relevant knowledge and an updated skill set can empower your team, and help you stay ahead of the game in the areas of technology, design techniques, project management, and coding languages.

How Knowledge Debt Can Harm Your Business

Technical Debt

In software development, technical debt occurs when the technology your software developers are using becomes difficult to maintain, or when a specific technical project your company is working on hits a brick wall. The technology in question could be anything including, but not limited to:

  • software
  • applications
  • code
  • software
  • language
  • electronic equipment hardware
  • technical knowledge

Although the version of each of these may offer the perfect solution initially, over time, they risk accumulating technical debt by falling short of updated requirements and advances in software development.

And unfortunately, the problem doesn’t just lie with the fact that your team is using outdated software and coding. The real issues occur when products and applications which were built on old technologies become unsupported as a result.

Software engineer Erik Edgar explains that the moment your application is no longer supported, your team is thrown into tech debt. For example, if a developer tries to add customizations to an older application version which is no longer supported, then these attempts at customization may cause the app to fail, often beyond repair. This also takes its toll on customer service, as an unsupported application or code-base won’t readily have access to vendor help.

It also means that when client the client wants to make any changes to their product, whether it’s a website or an app, if it turns out that it is now unsupported, they will have to refer directly back to the developer who built it. This causes problems when the client wishes to switch vendors, redesign the product, or if they are unable to get in contact with the incumbent.

Skills and Knowledge

As for learning new skills, Erik also mentions how initially, as an Oracle developer he didn’t need to know Java, but since then the necessary code bases have evolved and frameworks have changed which means that developers need to constantly keep their skill set relevant.

How to Reduce Knowledge Debt

While you may not be able to completely prevent knowledge debt, with the right approach, it is definitely possible to reduce it.

1. Prioritize a flexible and diverse skill set.

Many employers will encourage developers to stick with the code base which will meet current needs, rather than challenge themselves with learning alternatives on the side or introducing new software languages.

However, the title of full-stack developer now demands a flexible and diverse skill set, which is prepared to meet the potential pitfalls of the technical team which may occur down the line. Moral of the story - don't put all your eggs in one technical basket.

One of the many challenges of engineering leadership in executing on this topic is that they don’t have visibility into how much each language or one expert is having on their overall code base. For example, if only 1 member of your workforce knows Java, but your most mission-critical repos and 75% of all code is in Java, it may be time to hire an additional member with that skill set. Tools like Gitalytics can help with increased visibility into what’s happening with the skills the team has and the code base.

2. Know when it’s time to let go.

This one is intuitive. When a code language is obviously not supported or in use anymore, don’t make it part of your services, and certainly don’t build new products with it.

3. Encourage Empowered, Rapid Learning.

Although of course it still stands that quantity does not always equal quality, your developers need to practice rapid learning techniques. As well as providing your team with access to necessary training, it’s important that they can keep up with this pace and not allow themselves to get comfortable with their current skill set.
Encourage empowered learning amongst your team, and the importance of taking initiative. Because no one codes in COBOL, Fortran, C, C++, Modula, Lisp, Perl, or Pascal anymore - at least, not the big shots!*grlyc-3M-OB010Xp.jpg

4. Assign Technical Leads.

The most technical members of the team should take on the role of Technical Leads. Engineer Oren Ellenbogen argues that “We don’t need more software architects. We need more teachers and mentors to amplify our people rather than our software.” Technical Leads should monitor experience levels, knowledge gaps, migration and back-up plans, milestones, and training. This will help your team track knowledge debt and keep it under control.

5. Review, Review, Review.

Both self-reviews and peer-reviews are vital to reducing technical debt, and provide your team with actionable goals and tangible outcomes. So, ask yourself the right questions. If you no longer have faith in your current systems, and if the signs are all there that they need to be replaced, then you know you need to change your model.
Competitive analysis is also key. Keep an eye out for what other tech teams are doing, and the latest pioneering techniques. You might even be able to come up with a few of your own!