Articles

Technical Debt: Interview With Adam Tornhill and Alex Omeyer

,

Last week we hosted a webinar where Alex Omeyer interviewed Adam Tornhill about technical debt: what is it, why it’s important, and how to manage it effectively. For this article, we’ve chosen some of the most interesting questions we’ve got from the audience. If you’re curious to learn more — check out the full version of the webinar.

Alex: I’m Alex, the Co‑founder, and CEO of Stepsize. I spend all of my time talking about technical debt with Engineering team members, and I’m genuinely pumped to have Adam, CTO and Founder of CodeScene, with me today.

Source de l’article sur DZONE

/par

Technical Debt Affects Everyone

,

If you’ve read our piece about the habits engineers need to beat tech debt, you might recall Conway’s law, which states that organizations which design systems […] are constrained to produce designs that are copies of the communication structures of these organizations.

It’s one of the forces that can push us towards technical bankruptcy because the systems designed by software engineers are constrained by their company’s organizational structure, over which they have little control. The right way to fight these forces is to talk about tech debt across the whole company so that everyone can understand why it’s vital to manage it carefully.

Source de l’article sur DZONE

/par

What Technical Debt Is and How to Calculate It

,

In an ideal world, every project is finished on time, and within the estimated budget. Even better, the budget has allowed teams to develop additional features and test everything one more time before the release. In the real world, the development process can encounter several difficulties, and technical debt is among the most common issues the project may face. It is essential to understand what technical debt is, how to evaluate it and especially how to tackle it.

What Is Technical Debt?

Technical debt is the additional work needed to complete the software development. But this notion does not refer solely to the projects that are in development. This issue often follows the projects that have been production for some time. This may be anything, like some module written on legacy technology, that holds the project back from including a new functionality or influence overall software stability. In this particular case, technical debt can be calculated as the time or money needed for the refactoring of this module’s code or porting it to the new technology. But usually it is never that simple and the software system includes a number of drawbacks that can be included in the technical debt of the project.

Source de l’article sur DZone (Agile)

/0 Commentaires/par