Tackling technical debt in post-covid software development

Business news |
By Nick Flaherty

When Covid-19 first struck, IT teams had to scramble to carry out jobs and implement processes to ensure a smooth transition to home working. Making this happen has create ‘technical debt’ that needs to be addressed, says Łukasz Koczwara, VP of Engineering at STX Next, Europe’s largest Python house.

The awareness of technical debt accrued both in the last 12 months and in general is better than it was before, now is the time to redouble efforts to tackle it across the product development lifecycle in the long term, he says.

“The pressure on software developers to reduce time to market on products and services has intensified recently, which has inevitably led to an accumulation of technical debt,” he said. “This was exacerbated in the early stages of the pandemic, where IT teams understandably took on a certain level of technical debt to keep the lights on – desperate times call for desperate measures after all.”

This technical debt comes from cutting corners in IT processes and the subsequent challenges this can lead to further down the line. For example, there might be a demand on the IT department to get a particular project completed quicker than would be ideal, so the IT team puts something together that does the job in the short term, but is imperfect and will likely need further work down the line to patch any issues and ensure long-term success.

This can create problems if too much technical debt is allowed to build up as it can lead to a lot of extra work for IT teams. A certain level of technical debt will likely always exist, but organisations need to embrace a philosophy that emphasises frequent and detailed testing, measurement and evaluation of the entire development lifecycle.

The company, headquartered in Poland, has 250 engineers working on a wide range of Python projects and so is seeing the challenges building up.

“We’ve seen that IT departments have also become much more aware of the exponential costs of technical debt in general in the last couple of years. They recognise that quality matters, so are less likely to cut corners in development processes,” he added. “In addition, there are lots of frameworks and third-party software options now that make monitoring technical debt much easier.

“IT challenges have also stabilised since the early months of the pandemic, meaning there’s no time like the present for organisations to press home the advantage and look closely at whether their emphasis on technical debt reduction is sufficient.”

While the total elimination of technical debt is unlikely, Koczwara points to a range of different measures to keep tabs on projects, focusing heavily on frequent measuring, monitoring and evaluation.

“At the end of the day, you can’t improve what you don’t measure. This means having monitoring tools in place that enable team members to keep a close eye on the development process and ensure shortcuts aren’t being taken, as well as frequent and comprehensive testing,” he said.

 “Continuous integration and continuous development should be standard practice for a start. This should be supplemented with initiatives such as ‘bug squash days’ – where any potential issues are identified and addressed in a single day – and retrospective sessions where IT teams and the wider organisation conduct an honest evaluation of a project, by analysing both processes and technology.”

“The key is to recognise that technical debt is applicable to every part of the software development lifecycle. With a thorough approach that incorporates every job, process, team and individual, technical debt need not be the issue it once was.”

Related articles 

Other articles on eeNews Europe 


Linked Articles
eeNews Europe