8 Best Practices To Reduce Technical Debt

When past actions in software development return to haunt you…

Is your business being bogged down by technical debt? Let’s look at measures that you can take to reduce it and scale your operations without the weight pulling you back. 

 

Work with a flexible architecture.

Right from the word go, you want to use architecture whose design is malleable, especially with the rapid rate of software evolution witnessed today. Going with an architecture that keeps calling for too much refactoring, or whose design won’t accommodate future changes will leave you with costly technical debt. Use scalable architecture that allows you to modify or add new features in future releases. While on this, complex features required in the final product should be discussed at the planning stage, that way simplified solutions that will be easier to implement can be identified, as this will lead to less technical debt in the long run. 

 

The Deal with Refactoring 

This is basically cleaning up the code structure without changing its behaviour. With the updates, patches, and new functionalities that are added to the systems and applications, each change comes with the threat of more technical debt. Additionally, organisations are increasingly moving their IT infrastructure from on-premises facilities to colocation data centres and deploying them on the cloud. In such scenarios, some workarounds are often needed to enable the systems to function in the new environments, which they hadn’t been initially developed to accommodate. Here, you will need to take some time to refactor the existing system regularly, streamlining the code and optimizing its performance – and this will be key to pay down the tech debt. When working with a flexible architecture from the start, the amount of work that goes into this will be reduced, meaning there’ll be less tech debt involved. 

 

Run discovery tests

Discovery testing essentially takes place even before a line of code is written for the system or application. This takes place at the product definition stage, where human insight software is used to understand the needs of the customer and is particularly helpful in setting priorities for the development work that will be carried out. It gives your business the opportunity to minimize the technical debt by allowing customers to give you a roadmap of the most pertinent features desired from the product. 

 

Routine code review

Getting a fresh look at the product or application from different sets of eyes in the development team will improve the quality of the code, thus reducing technical debt. There’s a catch though – this should be planned in a convenient way that doesn’t end up becoming a burden for the developers. Here are suggestions:

● Break down pull requests

Instead of having complex pull requests where numerous changes in the code are introduced at a go, have this broken down into smaller manageable pull requests, each with a brief title and description about it. This will be easier for the code reviewer to analyse. 

● Define preferred coding practices

Documenting the preferred coding style will result in cleaner code, meaning the developers will focus their effort on reviewing the code itself, not losing time on code format debates.

 

Test automation

Relying only on scheduled manual testing opens you up to the risk of technical debt accruing rapidly, and not having sufficient resources to deal with the accumulated problems when they are identified. Automated testing on the other hand enables issues to be uncovered quicker, and with more precision. For instance, you can have automated unit tests that look at the functioning of the individual components of a system, or regression testing where the focus is on whether the code changes that have been implemented have affected related components of the system. However, establishing and maintaining automated testing will require quite some effort – making it more feasible for the long-term projects.

 

Keep a repository that tracks changes made

Do you have a record of changes made in the software? Keeping one in a repository that is accessible by the development team will make it easy to pin-point problems at their source. For instance, when software is being migrated to a new environment, or legacy software is in the process of being modernised, you will want to have an accurate record of changes that are being introduced, that way if there is an undesired impact on the system this it will be easier to zero-down on the cause.

 

Bring non-technical stakeholders on board

Does this conversation sound familiar?

Development Team: “We need to refactor the messy code quickly”

Product Team: “We have no idea what you are saying”

On one hand, you have the management or product team defining the product requirements, creating a project roadmap, and setting its milestones. On the other hand, there’s the software development/engineering that’s primarily focused on the product functionality, technical operations and clearing the backlog in code fixes. Poor communication between the two teams is actually a leading cause of technical debt.

For you to take concrete steps in managing your technical debt, the decision-makers in the organisation should understand its significance, and the necessity of reducing it. Explain to them how the debt occurred and why steps need to be taken to pay it down – but you can’t just bombard them with tech phrases and expect them to follow your thought process. 

So how do you go about it? Reframe the issues involved with the technical debt and explain the business value or impact of the code changes. Basically, the development team should approach it from a business point of view, and educate the management or production team about the cost of the technical debt. This can include aspects such as expenses in changing the code, salaries for the software engineers especially when the development team will need to be increased due to the workload piling up, as well as the revenue that is lost when the technical debt is allowed to spiral. 

The goal here is to show the management or production team how issues like failing to properly define the product requirements will slow down future software development, or how rushing the code will affect the next releases. That way, there will be better collaboration between the teams involved in the project. 

 

Allocate time and resources specifically for reducing technical debt

With management understanding that working with low-quality code is just like incurring financial debt and it will slow down product development, insist on setting time to deal with the debt. 

For instance, when it comes to the timing of application releases, meetings can be conducted to review short- and longer-term priorities. These meetings – where the development team and product team or management are brought together, the developers point out the software issues that should be resolved as a priority as they may create more technical debt. Management then ensures that budgets and plans are put in place to explicitly deal with those ongoing maintenance costs.

 

Retire old platforms

While most of the resources are going into developing new applications and improving the systems being used, the organisation should also focus on retiring the old applications, libraries, platforms, and the code modules. It’s recommended that you factor this into the application release plans, complete with the dates, processes and costs for the systems involved. 

 

Total overhaul

When the cost and effort of dealing with the technical debt far outweighs the benefits, then you may have to replace the entire system. At this tipping point, you’re not getting value from the technical debt, and it has become a painful issue that’s causing your organisation lots of difficulties. For instance, you may be dealing with legacy software where fixing it to support future developments has simply become too complicated. The patches available may only resolve specific issues with the system, and still leave you with lots of technical debt. Here, the best way out is to replace the system in its entirety. 

 

Final thoughts

Every software company has some level of tech debt. Just like financial debt, it is useful when properly managed, and a problem when ignored or allowed to spiral out of control. It’s a tradeoff between design/development actions and business goals. By taking measures to pay down your organization’s debt and address its interest as it accrues, you will avoid situations where short term solutions undermine your long-term goals. This is also key to enable your business to transition to using complex IT solutions easier, and even make the migration between data centres much smoother. These 8 measures will enable you to manage your technical debt better to prevent it from being the bottleneck that stifles your growth.

Check our similar posts

What ISO 14001 Status did for Cummins Inc.

Cummins manufactures engines and power generation products, and has been a household name almost since inception in 1919. It sells its products in over 300 countries, through approximately 6,000 dealerships employing 40,000 people. Because its product line runs off fossil fuel it is under steady pressure to display a cleaner carbon footprint.

Cummins decided to go for the big one by qualifying for ISO 14001 certification. This is a subset of a family of standards relating to managing environmental impact while complying with all applicable legislation. In this sense, it is similar to the ISO 9000 quality management system, because it focuses on how products are produced (as opposed to how those products perform). Compliance with ISO 14001 was a doubly important goal, because it is part of the European Union?s Eco Management and Audit Scheme and fast becoming mandatory on suppliers to governments.

The qualification process follows the well-established principle of plan, do, check, act. It begins with gap analysis to detect materials and processes that affect the environment. This is followed by implementation of necessary changes affecting operations, documentation, emergency strategies and employee education. The third step involves measuring and monitoring performance. Finally, the project moves into a phase of ongoing maintenance, and continuous improvement as circumstances change.

In Cummins case, the project was almost worldwide and called for environmental, health and safety reporting throughout the organisation. The information was shared via a globally accessible document repository, and then processed centrally at the head office in Columbia, Indiana USA.

Measuring environmental performance almost inevitably has other benefits that make it doubly worthwhile. Speaking at the 2014 National Safety Council Congress after receiving the top award for excellence, Cummins chairman and ceo Tom Linebarger commented on a journey that was ?nothing short of amazing? yet wasn’t even a ?pathway to the finish line?.

?All of us feel like we have way more to do to make sure that our environment is as safe as it could be,? he added, ?so that our sustainability footprint is as good as it can be and that we continue to set more aggressive goals every year. That’s just how we think about it.? Linebarger concluded.

If you are taking your company on a journey to new heights of environmental excellence, then you should consider choosing ecoVaro as your travelling companion. We are environmental management specialists and have proprietary software geared to process your data. We also have a wealth of experience, and a treasure chest of roadmaps to help you achieve your goal.

Making Click-and-Collect click

In my previous post, I introduced you to integrated e-commerce and explained why it is the right way to extend your business online. If you already have a brick-and-mortar retailing business and you’re looking to improve your online presence, you could start offering a click-and-collect service.

With click-and-collect, customers order online and then collect their merchandise from one of the retailer?s local branches. Why would they want to do that?

Apparently, there are buyers who now prefer a click-and-collect service over the delivery service of a purely online retailer. With the latter, they sometimes have to wait forever for the delivery van to arrive or contend with a missed-delivery card.

Basically, customers who want both the convenience of placing orders online and better control of their time find click-and-collect a better option.

Last December 2011, IMRG (Interactive Media in Retail Group) reported a ?significant rise in the percentage of click-and-collect e-retail sales in the 3rd quarter of 2011?. This accounted for 10.4% of all e-retail sales in that quarter. More specifically, the gain was 7.4%, which was also the strongest quarterly gain since IMRG started collecting this data.

Clearly, this particular service is gaining popularity. But how do you meet the rising demand in this area?

A click-and-collect service requires a highly synchronised ecosystem. You don’t want to have a customer order items from your online store, drive a couple of minutes from his house to your nearest outlet, only to find out that one of the items is no longer available.

This can only work if all systems involved are interconnected. Changes in the inventory in your individual outlets should reflect on your database in real time. In turn, these changes have to be reflected instantly on your online store. Conversely, once a buyer has picked items online and is already directed to a local outlet, those items have to be reserved there.

But that’s not all. Your system has to be seamless enough to support fast and reliable service. You don’t want your buyer to have to wait a long time before the items are ready for pick-up. It also has to be capable of tracking the status of ordered products, handling uncollected orders, and monitoring inventory.

By implementing an integrated e-commerce system, these won’t be the only things you?d be able to do. You can even add more value to your service. For example, you can connect to your CRM and learn more about your customers? purchase history, buying habits, and preferences.

That way, it would be easier for you to provide a faster and more convenient buying experience for them in the future.

Click-and-collect is a very promising way to increase your sales and improve customer loyalty.

Benefits Realisation Frameworks – A Useful Handle

One of the greatest challenges of project management is maintaining top-down support in the face of fluctuating priorities. If you elect to take on the role yourself and are peppered by other priorities, it can be a challenge to exactly remember why you are changing things and what your goals are. Sometimes you may not even notice you have reached your goal.

The Benefits Realisation Chart-room

The Benefits Realisation Model is a framework on which to hang key elements of any project. These traditionally include the following, although yours may not necessarily be the same:

  • Definition of the project goal
  • Quantification of intended benefits
  • Project plan versus actual progress
  • How you know you reached your goal
  • Quantification of actual benefits

Another way of describing Benefits Realisation Frameworks is they answer four fundamental questions that every project manager should know by heart:

  • What am I going to do?
  • How am I going to do it?
  • When will I know it’s done?
  • What exactly did I achieve?

The Benefits Realisation Promise

An astounding number of projects fail to reach completion, or miss their targets. It’s not for nothing that the expression ?after the project failed the non-participants were awarded medals? is often used in project rooms. We’re not saying that it is a panacea for success. However it can alert you to warnings that your project is beginning to falter in terms of delivering the over-arching benefits that justify the effort.

When Projects Wander Off-Target

Pinning blame on participants is pointless when project goals are flawed. For example, the goals may be entirely savings-focused and not follow through on what to do with the windfall. At other times realisation targets may be in place, but nobody appointed to recycle the benefits back into the organisation. This is why a Benefits Realisation Framework needs to look beyond the project manager?s role.

Realisation Management in Practice

If the project framework does not look beyond the project manager?s role, then it is over when it reaches its own targets ? and can even run the risk of being an event that feeds entirely off itself. In order to avoid a project being a means to its own end, this first phase must culminate with handover to a benefits realisation custodian.

An example of this might be a project to centralise facilities that is justified in terms of labour savings. The project manager?s job is to build the structure. Someone else needs to rationalise the organisation.

In conclusion, the Benefits Realisation Framework is a useful way of ensuring a project does not only achieve its internal goals, but also remains a focus of management attention because of its extended, tangible benefits.

Ready to work with Denizon?

Contact Us Today