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

Why Executives Fail & How to Avoid It

The ?Peter Principle? concerning why managers fail derives from a broader theory that anything that works under progressively more demanding circumstances will eventually reach its breaking point and fail. The Spanish philosopher Jos? Ortega y Gasset, who was decidedly anti-establishment added, “All public employees should be demoted to their immediately lower level, as they have been promoted until turning incompetent”.

The Peter Principle is an observation, not a panacea for avoiding it. In his book The Peter Principle Laurence J. Peter observes, “In a hierarchy every employee tends to rise to his level of incompetence … in time every post tends to be occupied by an employee who is incompetent to carry out its duties … Work is accomplished by those employees who have not yet reached their level of incompetence.”

Let’s find out what the drivers are behind a phenomenon that may be costing the economy grievously, what the warning signs are and how to try to avoid getting into the mess in the first place.

Drivers Supporting the Peter Principle

As early as 2009 Eva Rykrsmith made a valuable contribution in her blog 10 Reasons for Executive Failure when she observed that ?derailed executives? often find themselves facing similar problems following promotion to the next level:

The Two Precursors

  • They fail to establish effective relationships with their new peer group. This could be because the new member, the existing group, or both, are unable to adapt to the new arrangement.
  • They fail to build, and lead their own team. This could again be because they or their subordinates are unable to adapt to the new situation. There may be people in the team who thought the promotion was theirs.

The Two Outcomes

  • They are unable to adapt to the transition. They find themselves isolated from support groups that would otherwise have sustained them in their new role. Stress may cause errors of judgement and ineffective collaboration.
  • They fail to meet business objectives,?but blame their mediocre performance on critical touch points in the organization. They are unable to face reality. Either they resign, or they face constructive dismissal.

The Warning Signs of Failure

Eva Rykrsmith suggests a number of indicators that an individual is not coping with their demanding new role. Early signs may include:

  • Lagging energy and enthusiasm as if something deflated their ego
  • No clear vision to give to subordinates, a hands-off management style
  • Poor decision-making due to isolation from their teams? ideas and knowledge
  • A state akin to depression and acceptance of own mediocre performance

How to Avoid a ?Peter? in Your Organization

  • Use succession planning to identify and nurture people to fill key leadership roles in the future. Allocate them challenging projects, put them in think tanks with senior employees, find mentors for them, and provide management training early on. When their own manager is away, appoint them in an acting role. Ask for feedback from all concerned. If this is not positive, perhaps you are looking at an exceptional specialist, and not a manager, after all.
  • Consider the future, and not the past when interviewing for a senior management position. Ask about their vision for their part of the organization. How would they go about achieving it? What would the roles be of their subordinates in this? Ask yourself one very simple question; do they look like an executive, or are you thinking of rewarding loyalty.
  • How to Avoid Becoming a ?Peter??Perhaps you are considering an offer of promotion, or applying for an executive job. Becoming a ?Peter? at a senior level is an uncomfortable experience. It has cost the careers of many senior executives dearly. We all have our level of competence where we enjoy performing well. It would be pity to let blind ambition rob us of this, without asking thoughtful questions first. Executives fail when they over-reach themselves, it is not a matter of bad luck.

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK
A Definitive List of the Business Benefits of Cloud Computing

When you run a Google search for the “benefits of cloud computing”, you’ll come across a number of articles with a good list of those. However, most of them don’t go into the details, which nevertheless might still suit some readers. But if you’re looking for compelling business reasons to move your company’s IT to the cloud, a peripheral understanding of what this technology can do for you certainly won’t cut it.

Now, cloud computing is not just one of those “cool” technologies that come along every couple of years and which can only benefit a particular department.?What we’re talking about here really is a paradigm shift in computing that can transform not only entire IT infrastructures but also how we run our respective organisations.

I hate to think that some people are holding back on cloud adoption just because they haven’t fully grasped what they’re missing. That is why I decided to put together this list. I wanted to produce a list that would help top management gain a deeper understanding of the benefits of the cloud.

Cloud computing is one bandwagon you really can’t afford not to jump into. Here are ten good reasons why:

1.?Zero?CAPEX and low TCO for an enterprise-class IT infrastructure

2. Improves cash flow

3. Strengthens business continuity/disaster recovery capabilities

4. Lowers the cost of analytics

5. Drives business agility

6. Ushers in anytime, anywhere collaboration

7. Enhances information, product, and service delivery

8. Keeps entire organisation in-sync

9. ?Breathes life into innovation in IT

10. Cultivates optimal environments for development and testing

Zero CAPEX and low TCO for an enterprise-class IT infrastructure

Most cloud adopters with whom I’ve talked to cite this particular reason for gaining interest in the cloud.

Of course they had to dig deeper and consider all other factors before ultimately deciding to migrate. But the first time they heard cloud services could give them access to enterprise class IT infrastructures without requiring any upfront capital investment, they realised this was something worth exploring.

A good IT infrastructure can greatly improve both your cost-effectiveness and your capability to compete with larger companies. The more reliable, fast, highly-available, and powerful it is, the better.

But then building such an infrastructure would normally require a huge capital investment for networking equipment, servers, data storage, power supply, cooling, physical space, and others, which could run up to tens or even hundreds of thousands of euros. To acquire an asset this costly, you’d have to take in debt and be burdened by the ensuing amortisation.

If you’ve got volumes of cash stashed in your vault, cost might not be a problem. But then if you really have so much savings, wouldn’t it be more prudent to use it for other sales-generating projects? An extensive marketing endeavour perhaps?

A capital expenditure of this magnitude and nature, which normally has to be approved by shareholders, can be regarded as a high financial risk. What if business doesn’t do well and you wouldn’t need all that computing power? What if the benefits expected from the IT investment are not realised??You cannot easily convert your IT infrastructure into cash.

Remember we’re talking about a depreciating asset. So even assuming you can liquidate it, you still can’t hope to sell it at its buying price. These factors are going to play in the minds of your Board of Directors when they’re asked to decide on this CAPEX.

Incidentally, these issues don’t exist in a cloud-based solution.

A cloud solution typically follows a pay-as-you-go utility pricing model where you get billed monthly (sometimes quarterly) just like your electricity. ?In other words, it’s an expense you’ll need to pay for?at the end of a period over which the service’s value would have already been realised. Compare that with a traditional infrastructure wherein you’ll have to spend upfront but the corresponding value will still have to be delivered gradually in the succeeding months or years.

demand expense traditional infrastructure

From the point of view of your CFO, what could have been a CAPEX to acquire an asset that depreciates with time (and consequently reduces your company’s net worth), becomes a flexible operating expense (OPEX).?Truly, it is an operating expense that you can increase, decrease, or even totally discontinue, depending on what the prevailing business conditions demand.

demand expense cloud infrastructure

People who think they have done the math in comparing cloud-based and traditional IT infrastructures claim that, although they see how cloud solutions transform CAPEX into OPEX, they really don’t see any significant difference in overall costs.

However, these people have only gone as far as adding up the expected monthly expenses of a cloud solution over the estimated duration of an equivalent IT infrastructure’s effective lifespan and comparing the sum with that IT infrastructure’s price tag. You won’t get a clear comparison that way.

You need to consider all factors that contribute to the infrastructure’s Total Cost of Ownership (TCO). Once you factor in the costs of electricity, floor space, storage, and IT administrators, the economical advantages of choosing a cloud solution will be more evident. Add to that the costs of downtime such as: interruptions to business operations, technical support fees, and the need to maintain expensive IT staff who spend most of their time “firefighting”, and you’ll realise just how big the savings of cloud adopters can be.

Still not convinced? Well, we’re still getting started.?On our next post, we’ll take a closer look at the additional benefits of paying under an OPEX model instead of a CAPEX model.

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK
Spreadsheet Woes – Burden in SOX Compliance and Other Regulations

End User Computing (EUC) or end User Developed Application (UDA) systems like spreadsheets used to be ideal ad-hoc solutions for data processing and financial reporting. But those days are long gone.

Today, due to regulations like the:

  • Sarbanes-Oxley (SOX) Act,
  • Dodd-Frank Act,
  • IFRS (International Financial Reporting Standards),
  • E.U. Data Protection Directive,
  • Basel II,
  • NAIC Model Audit Rules,
  • FAS 157,
  • yes, there?s more ? and counting

a company can be bogged down when it tries to comply with such regulations while maintaining spreadsheet-reliant financial and information systems.

In an age where regulatory compliance have become part of the norm, companies need to enforce more stringent control measures like version control, access control, testing, reconciliation, and many others, in order to pass audits and to ensure that their spreadsheets are giving them only accurate and reliable information.

Now, the problem is, these control measures aren’t exactly tailor-made for a spreadsheet environment. While yes, it is possible to set up a spreadsheet and EUC control environment that utilises best practices, this is a potentially expensive, laborious, and time-consuming exercise, and even then, the system will still not be as foolproof or efficient as the regulations call for.

Testing and reconciliation alone can cost a significant amount of time and money to be effective:

  1. It requires multiple testers who need to test spreadsheets down to the cell level.
  2. Testers will have to deal with terribly disorganized and complicated spreadsheet systems that typically involve single cells being fed information by other cells in other sheets, which in turn may be found in other workbooks, or in another folder.
  3. Each month, an organisation may have new spreadsheets with new links, new macros, new formulas, new locations, and hence new objects to test.
  4. Spreadsheets rarely come with any kind of supporting documentation and version control, further hampering the verification process.
  5. Because Windows won’t allow you to open two Excel files with the same name simultaneously and because a succession of monthly-revised spreadsheets separated by mere folders but still bearing the same name is common in spreadsheet systems, it would be difficult to compare one spreadsheet with any of its older versions.

But testing and reconciliation are just two of the many activities that make regulatory compliance terribly tedious for a spreadsheet-reliant organisation. Therefore, the sheer intricacy of spreadsheet systems make examining and maintaining them next to impossible.

On the other hand, you can’t afford not to take these regulations seriously. Non-compliance with regulatory mandates can have dire consequences, not the least of which is the loss of investor confidence. And when investors start to doubt the management’s capability, customers will start to walk away too. Now that is a loss your competitors will only be too happy to gain.

Learn more about our server application solutions and discover a better way to comply with regulations.

More Spreadsheet Blogs


Spreadsheet Risks in Banks


Top 10 Disadvantages of Spreadsheets


Disadvantages of Spreadsheets – obstacles to compliance in the Healthcare Industry


How Internal Auditors can win the War against Spreadsheet Fraud


Spreadsheet Reporting – No Room in your company in an age of Business Intelligence


Still looking for a Way to Consolidate Excel Spreadsheets?


Disadvantages of Spreadsheets


Spreadsheet woes – ill equipped for an Agile Business Environment


Spreadsheet Fraud


Spreadsheet Woes – Limited features for easy adoption of a control framework


Spreadsheet woes – Burden in SOX Compliance and other Regulations


Spreadsheet Risk Issues


Server Application Solutions – Don’t let Spreadsheets hold your Business back


Why Spreadsheets can send the pillars of Solvency II crashing down

?

Advert-Book-UK

amazon.co.uk

?

Advert-Book-USA

amazon.com

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Ready to work with Denizon?