In the process of software development, many unforeseen challenges can arise. From internal business pressures to collaboration issues and weaknesses in technical leadership; any number of issues can impact the final product.
While the goal of software developers is to create the most effective and user friendly end product, time pressures and hard deadlines can result in development teams being driven to make products that can sometimes be completed containing imperfect or incomplete code.
Technical debt in software development refers to the cost of reworking software later down the line, after the initial work has been completed, due to developers choosing to prioritise on-time delivery, over a polished piece of software.
Paying off debt
All software teams will face technical debt with there being a range of different forms that debt takes during software development. According to Martin Fowler’s Technical Debt Quadrant, each of these different forms of debt can be placed into one of four overarching categories for definition, deliberate or inadvertent, and then defined again as either reckless or prudent.
As the name suggests, deliberate debt is debt that developers know about but due to a myriad of reasons decide the best course of action is to ship now and later fix the issue. The second form of debt is inadvertent, which is where debt can be created without developers realising at the time and it is only discovered down the line.
The first step of paying this technical debt is to accurately define the exact form this debt takes, namely if it is design debt, documentation debt, a code debt or a build debt, alongside many other types of debt.
Long-term challenges
Unless the issue of technical debt is faced head-on, enterprises will need to make “interest payments” for the foreseeable future. In practice, waiting to deal with these issues simply means that they will have to be addressed in the future by another developer.
While there will always be a tension between the need to reduce development times to bring products to market sooner and the actual time needed by developers to create effective software, engaging the entire business ecosystem on the impact of technical debt can be a powerful way to reduce its prevalence.
Once IT and business leaders are aware of the challenges developers will face if they are not supported in driving down technical debt, they are more likely to help by either compromising on delivery dates, adding new members to the team or freeing-up funding for new tools.
Creating automated tests to fix bugs that reappear can go a long way to immediately addressing bugs that will not be found and can turn into technical debt. There is no question that if developers have access to modern IT development tools across the board, it is likely when code is being written it will follow best practices and errors will fall.
No one-size-fits-all approach works to reduce the creation of new technical debt and pay off existing debt quickly, with a range of business areas playing a role in this journey. From recruiters prioritising high-quality developers to IT leaders supporting their teams to only produce high-quality code and business executives providing the necessary funding; only by working together can a business reduce technical debt.
Despite the best efforts by technological leaders and individual developers, completely overcoming technical debt is a major challenge and cannot be achieved overnight. But by clearly defining the scale of technical debt at an organisation and setting new standards going forward to ensure past mistakes do not repeat themselves, the impact of technical debt will likely fall. This will enable developers to focus on what they do best; create powerful software.
from Software Development – My Blog https://ift.tt/O9MyV0b
via IFTTT
No comments:
Post a Comment