Is The Impact Of Technical Debt The Same Everywhere?

by

Technical debt is defined, in this post, as any code that impedes agility as a project matures. This is an important definition to keep in mind as the following attitude towards technical debt is discussed.

One of the reasons that so many start ups fail is because they take too long to get their product to market, and it causes marketing efforts to stand still or become irrelevant. This allows the competition to come in and take away the market opportunity. It is therefore possible to say that a software company’s success has less to do with having perfect code or systems and more to do with delivering  an efficient and valuable product to market at the right time. It is not realistic to design a product for first launch that is entirely perfect – it will often take several iterations of change and feedback to have the product reach its full potential.

It is then interesting to question why building software is seen in a manner that does not match the reality of how projects and products are produced and launched. A good comparison made in this post is to the construction of some of the world’s largest cities – New York and London were not built with the prospect of housing millions of people in mind, but they improved overtime and added infrastructure to accommodate these changes. This demonstrates the issue with an engineer wanting to  scale their project for one million users in the first launch – the possibility of that traffic is slim and therefore unneeded resources were spent building for it.

When discussing how to manage technical debt, in strategy, there are certain areas that require more attention than others. There are also areas that require intense scrutiny and a hard line against accruing technical debt. This sort of strategy demands an awareness of what aspects of a product need the ability to change rapidly. It is then okay to state that some areas of an app or project are not at serious risk by incurring technical debt. The reasoning behind such a conclusion is that technical debt hampers agility and makes the process of making changes in an application much slower, but this is a disadvantage only if an area requires a lot of change.

**Disclaimer: technical debt is not buggy code or a system that is broken – because these issues will cause damage to code if left alone.

Considering how it has been stated that there are areas in a code base which require more attention than others regarding technical debt, what are these so called areas that are more at risk to the presence of technical debt?

They are the following:

  • User Interfaces – this part of an application requires considerable change and therefore needs to remain agile in order to be able to accept changes quickly and effectively. This has contributed to the popularity of single page applications – they allow for quick agility without API changes.
  • Data Structures – it is said that bad programmers worry about the code, while good programmers worry about the data. The first part of any project should be dedicated to ensuring that its data structures are well done. For example, if a relational database is being used and modules are awkwardly placed, it will incur massive frustrations later on.

The best method to implement a strategy that will allow a different levels of attention with regard to technical debt (depending on the area most vulnerable to it) would be to segment the code base into specific areas of concern. If the work is divided into separate ‘silos’ then it will not matter if there is substantial technical debt in one area because the system has been decoupled. When putting in testing into place, the areas where the most traffic is expected needs to have the most extensive testing applied.

The general concept of this post is to know the impact and larger perspective of what is being worked on – so as to be able to prioritize in managing technical debt. The final conclusion is that technical debt is often fine to have, as long as it is taken care of in a savvy manner and is used to get to market as quickly and as effectively as possible.

To read the full post go to: http://bigeng.io/post/118399425343/why-the-way-we-look-at-technical-debt-is-wrong

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|