How Recruiting The Right Tech Talent Can Solve Tech Debt

Now and then we read about a new, all-important parameter of software development that has technical teams buzzing. However, before we get carried away with the latest buzzwords that the industry is enamored with, it might help to look back at the thought processes that got us to where we are today.

One such concept has been floating around in the industry since 1992, following a talk by Ward Cunningham, who co-authored the Manifesto for Agile.

It’s called ‘Technical Debt’.

 

What is ‘Technical Debt’?

 

For multiple reasons, companies sometimes have to prioritize speed over matters such as code quality, documentation, and the aim of creating code that degrades gracefully. This compromise is precisely what leads to accruing ‘Technical Debt’.

In other words, it is the ‘cost’ that companies ‘borrow’, to ensure speedy delivery, with the understanding that the tech team needs to pay off the ‘interest’. In simpler words, the team needs to refactor the codebase even after delivery to ensure that coding standards are met, and the delivered product or service remains trouble-free.

David Cunningham perhaps put it best when he said, “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt.”

Why does it occur?

 

Martin Fowler, the chief scientist at ThoughtWorks built upon David Cunningham’s idea and created the ‘Technical Debt Quadrant’ in 2009. Fowler’s quadrant takes into account two key factors that could help teams understand if they are taking on technical debt for the right reasons: Intent and Context.

Martin Fowler categorized technical debt based on intent and prudence.

While technical debt is indeed seen in every facet of the tech industry, the fact is that it is nearly ubiquitous in the startup ecosystem. The reason for this can be clearly understood when you consider what Fowler outlined in his quadrant.

Most startups live and breathe in the top-right quadrant, where the need to be first-to-market is extremely pressing – making technical debt as common as coffee in the startup ecosystem.

Another key reason why the technical debt exists is because of the differences in priorities and comprehension, between the technical and business areas of a company.

Bridging the gap between new technology and its business use cases has been important since before the first-ever tech product was built, and will continue to linger on, in the tech industry. The dilemma of ‘building a technically-deep solution’ versus a solution that ‘ticks all boxes about the business need’ will forever remain, especially given the limited timeframes within which tech products are sometimes developed.

This dilemma leads to a de-prioritization of efforts that are aimed at reducing the technical debt of a product. After all, technical debt is hard to understand or visualize, so non-tech people often underestimate its consequences, and developers often put it on the backburner in the face of other pressing business tasks.

How does one identify and remedy technical debt?

 

Although technical debt is universal, identifying it requires a bit of reading between the lines. As per the Linux Foundation, the following are symptoms that can help identify the presence of technical debt:

• The increase in time needed to introduce new features

If the codebase isn’t built with a clear architecture and modularity, it naturally becomes harder to introduce new features.

• The necessity for intensive knowledge transfers

Codebases with high technical debt make for longer onboarding times because certain aspects of the code can only be understood by insider developers. It also makes it hard to hire new developers.

 

• Security concerns

The harder it gets to identify and fix errors in the codebase, the easier it is to exploit it.

• High maintenance costs

Code written in a hurried or undisciplined manner will always take longer and costs more to maintain.

• Lack of alignment with the bigger picture

More often than not, difficulty to keep up with the development and release cycle is a result of technical debt.

So now we know what technical debt is, and how it can be identified. We also understand that good tech teams have little technical debt.

So, what can be done to remedy technical debt?

 

Before we try to outline ways in which we can alleviate technical debt, we need to understand that it is absolutely necessary. Some releases simply can’t be delayed and some deadlines just can’t be negotiated with. So, incurring technical debt is necessary to stay afloat in many situations. However, that doesn’t mean that we should ignore the consequences. Tech teams must harvest a healthy attitude with technical debt, where they incur the debt in a prudent manner, while constantly making efforts to minimize tech debt.

• Consistently refactoring the codebase

Although it is easy to ignore refactoring because it is an effort that causes no visible changes on the outside, it is actually crucial to lowering technical debt. A disciplined approach to refactoring leads to a codebase that is low-maintenance, highly readable as well as highly functional, all while bringing down technical debt.

• Going open source

Development effort that is in line with a larger upstream open source project can reduce the technical debt massively in the long run. By minimizing the technical debt of a module and consistently making it a part of the open-source infrastructure, any redundancy is weeded out.

• Diligent documentation

In most cases, the comments within a piece of code, or the documentation of the codebase is just as important as the code itself. Among many reasons, this is the case because it makes it easier to reduce the technical debt. Digital documentation that colleagues can share with one another makes it easier to look up any information that is pertinent to a project and remove defects efficiently.

• Timely testing

A great way of reducing technical debt is to get rid of regression bugs. This can be done with the help of test automation tool that enables  more rigorous testing of every unit, along with testing of the whole product or service.

• Continuously improving the development strategy

High technical debt is almost always a red flag. It signals that the software development strategy was not designed as holistically as possible. This is why, the best way to keep technical debt low, is to modify the strategy as and when new roadblocks are overcome.

Hiring the right talent is the key

Given the necessity for and the consequences of high technical debt, as well the need for continuous retrospection of the codebase, it is clear that hiring the right talent is of supreme importance. The ‘secret’ behind building great tech products has never really been hidden. However, even though there were never any detractors from the notion that clean, well-documented code is what enables companies to scale to newer heights, there has always been inertia to do the ‘boring’ stuff.

All too often, tech teams get so carried away by the bigger picture, that they compromise on the very foundation of the software they are building.

So clearly, it isn’t just necessary to find talent that can create a working solution. It is also necessary to find talent that diligently creates a solution that is as sustainable as it is functional.

This is precisely why hiring the right talent can be an overarching strategy to help bring down the technical debt of a company. Teams could surely benefit from having a quality assessment tool that doesn’t just allow them to create tests that are in-depth but also enables them to recognize coding discipline and the flow of logic while solving a problem.

HackerEarth Assessments does just that. Thanks to its database of 12,000+ questions, detailed analytics, and powerful pair-programming capabilities, it has helped tech recruiters and hiring managers all over the world, with creating assessments that help match their teams to the exact skill set they need.