Technical Duty Interview
What is technical debt? Is it possible to understand him as a poor execution by developers of their duties? Is it possible to avoid the appearance of technical debt, and should it be avoided? How is technical debt related to the application architecture and trust between the customer and the contractor? What strategies are used to control technical debt?
I bring to your attention a translation of an interview published in the Software Enginering Radio podcast in April 2015. Sven Johan and Eberhard Wolf discuss the internal and external quality of the software, recall the generally accepted quality models and strategies aimed at maintaining the internal quality of the software. Technical debt is mainly considered in the context of managing software projects.
Wolf : So, the next release of Software Engineering Radio . This time, we will look at a single topic in the format of a classic interview. My guest is Sven Johan. He and I are co-authors of articles on the topic of technical debt, so that our thoughts, in many respects, coincide. Before we start, Sven, tell us about yourself?
Johan : My name is Sven Johan , I am a software developer at TRIFORK MCDM. I also participate in GOTO conferences, and I had the honor of holding the Microservices mitap.
WOLF : Sounds interesting. Well, my name is Eberhard Wolf , I am a freelance consultant, head of the advisory committee at Adesso AG, a speaker at German-speaking conferences, at the GOTO conference and at several others. I am also the author of the book on continuous software deployment. So, go to the topic.
')
Technical duty, no doubt, is associated with the characteristics of software quality. Therefore, it is worthwhile to first briefly recall first the theme of quality. Software quality is of two types: internal and external. The external quality of the software is exactly what the user or customer feels. This may be performance, there may be other qualities like security, stable operation, scalability, and so on. The external quality of the software can be assessed or measured objectively. It is part of the commercial value of the product, and it should be the focus of attention on the product and non-technical guidance.
The more difficult part to understand is the inner quality . Internal quality can only be assessed by developers and technicians; This includes everything that makes support and code development easier or harder. Tested this or that functionality, or flawed? Do tests provide easy code changes? Does the project benefit from good architecture, or is it experiencing architectural problems? This also includes the quality of the code, which may be too complicated or too simplified. The fact that this part is not visible from the side, complicates the situation. If you are not a technical specialist, it is difficult for you to assess the internal quality of the software and understand how it affects the development process.
How do you understand “technical debt”, Sven?
Johan : In principle, technical debt is a metaphor, which means a code with significant flaws. We compare technical debt with financial debt in order to clarify the considerations of the internal quality and technical risks of a software project to people who are not technical specialists. Nonspecialists rarely understand the difference between bad and good code. For them, it looks like “The product works, and it's great! Why should I invest in quality? ”
The term “Technical Debt” allows us to clarify that if we want to build something on the basis of a code with significant flaws, this will significantly increase the cost of project development in the future, including the expansion of functionality. In addition, a low internal quality will sooner or later manifest itself externally, and this must be understood. Poor quality code not only slows down the addition of functionality, but also can lead to the manifestation of a large number of bugs. As a result, it hinders the team so much that it becomes impossible to contain internal problems once - and they become problems for users, customers, and other interested parties.
In fact, technical debt is a problem of the scale of the company, and not an internal question of developers. There are cases when, due to a large technical debt, the engineering division of the company stopped entirely. I believe a lot of companies have had experience with 30-year systems in which making even a minor change is almost impossible.
Wolf : Yes, it can be argued that technical debt is one of the key factors affecting the commercial success of software. The term “technical debt” was proposed by Ward Könningham in 1992. Here is a quote:
As you can see, the metaphor directly mentions financial debt. It refers to the acceleration of supplies by borrowing; subsequently, you are forced to either repay debts or pay “interest”, which is manifested in the fact that your proactivity disappears, and the development slows down significantly. As Sven said, this metaphor is good for speaking with management, as they usually think in economic terms. That was the original definition. But there is an alternative definition, isn't it, Sven?
Johan : Of course. The scientific community rather prefers the definition of Steve McConnell . He formulates as follows:
I think this definition is more widespread. This is what we usually mean when we talk about “technical duty”: we do something quickly and ugly, getting immediate benefits - however, we know that in the long run this will hurt us.
Wolf : So we discussed the definition. But I think the most important thing is the actions you can take regarding technical debt, since it is one of the key factors for a successful business.
The first question, perhaps, is this: is technical debt really bad? If you think borrowing is not such a bad thing. If you bought a house on credit, you can no longer pay the rent; in the end, you will be left with a profit, so that such an investment can be profitable. For the same reason, industry is attracting loans to purchase more productive equipment that provides more output and more income. However, if you spend borrowed money to buy luxury goods, or gifts for the New Year, this could be a bad idea. In this case, the money is not invested, but spent without the possibility of their return.
Again, the metaphor suggests that the payment of debts does not always make sense. Why is that? Because, unlike a cash loan, you pay interest only if you change the code. The internal quality of the code is reduced to the possibilities of its change. And if the code is not subject to change, technical debt may not bother you. In fact, it is pointless to pay "debts" for those parts of the product that do not change.
There is another reason to forget about technical debt, because of which software development sometimes resembles the game “Minesweeper”: a person who has to pay debts is not necessarily the same person who creates them. If, in your case, one team is creating the product, and the other is supporting the product, then the first team is free from “interest payments”. In this case, the practical interests of the first team completely allow for the creation of a huge technical debt for rational reasons, since this can shorten the delivery time. This phenomenon must be remembered when we talk about the problem of technical debt. If you ignore it, it can cause confusion.
Johan : Yes. In a recent discussion, we’ve got to the point that technical debt is, in fact, a strategy. Why strategy? Because we can quickly achieve business goals in such a way, knowing that, for example, it is much more important to enter the market as soon as possible, rather than write a perfect code and be late. We may be the first among competitors or even the first in this area.
It is noteworthy that, for example, Eric Ric gave some data on this issue. In his book, he writes:
About a year ago, Henrik Nyberg from Spotify wrote a post on the same topic, where he said: “In general, we consider the perfect code as a waste of power, if we have no reason to believe that the functionality created by it will be really useful.” They extremely quickly develop functionality. The result is not perfect, but it is shown to the user. And if it turns out that the user likes it, and if it is intended to further develop this part of the code, they will refactor the code, bringing it to a normal state.
As we can see, uncomplicated strategies, applied over and over again, can be associated with such well-known success stories as Amazon and Twitter . As for Twitter, it seems that they are continuously rewriting the system. At the very beginning, Twitter was a Ruby on Rails application, and now it is an instant messenger. Amazon is also very different from what it was at the very beginning. I think these are all manifestations of strategy.
Wolf : That's right. If we talk about Amazon, one of the chapters of The City of Amazon (?) Tells us that at the very beginning, Amazon was a huge, monolithic application that was very difficult to maintain; and when the author of the book joined the company, the entire code was completely rewritten. One result of this refinement is beautiful architectural solutions known as the Amazon Cloud . It is important here that if Amazon were created with thoughts about high software quality and excellent scalability, it most likely would not have survived, as the team would not be able to create the functionality with the speed required. This is a great example of how a software product can be completely rewritten due to technical debt, but it turns out to be incredibly successful.
Johan : I think it was the same with Twitter, because initially they had no idea how many users they should count on. There is a significant difference: do you expect a thousand users, or a million, or one hundred million; but you still need to start somewhere.
WOLF : By the way, I would definitely mention this point in a situation where I would have to talk with software architects. I noticed that they too often raise scaling issues. It seems that software scalability is their main concern, while it would probably be better for them to focus on time-to-market . Otherwise, they have every chance not to see the moment when scalability is needed, since by that time the company may go bankrupt or the estimated source of profit will disappear.
As you can see, poor scalability is not always bad either. However, technical debt you somehow need to control. One of the best ideas I've come across belongs to Eric Evans . Evans is known as the author of the book Domain-Driven Design; and while one part of his approach regarding the use of uniform terminology, repositories and the like in a team is widely known, there is another part with which few seem to be familiar with. This is part of strategic design and design at the level of large-scale structures.
The essence of his idea is as follows: first of all, you cannot have the same quality of code in all parts of your system (generally speaking, this is a rather obvious point, if only because different team members differ in different quality of code; and even the best team is not homogeneous). What to do? Although you could just leave to chance, which parts of your system will be written well and which parts will be bad, it is better to make a conscious decision. One way to cope with technical debt is to ask yourself the question “Which parts of the system are really important, given current and future changes?” The answer can be found by examining the history of changes or looking at the subject area: which parts of the system will give us a competitive advantage if we Will we be able to quickly refine them? If, for example, delivery methods are very important for your store, it is reasonable to set a goal so that the part of the code responsible for this functionality has high internal quality. Evans, in his book, reviewed quite a few templates relating to this. The best of his ideas is that you can have boundaries between contexts, each of which gives a greater or lesser importance to a certain aspect of the subject area, and then between these contexts you can create a “protective layer”.
By applying this approach to the problem of internal quality, you could create a part of the system - in our example, responsible for the delivery of goods - with a really high-quality model of the domain where the quality and complex code is located, and the second part of the system, for example, responsible for interaction with the customer. in which parts of the code that are distinguished by low quality and mediocre modeling will “temporarily” dwell. To ensure that bad models do not affect your priceless delivery system, you create a protective layer that separates the two parts of the system and translates calls between them. Using this approach — I apply the “cell” metaphor for it, just like the cells of a living organism — you save each of the cells from penetrating external problems. This is a pretty good way to strategically manage quality and technical debt. You maintain some parts of the system at the highest level, constantly monitoring the quality, while for others you use standard, purchased or obsolete components. It seems to me that when developing fairly complex systems, this strategy deserves attention.
Johan : One of the well-known questions, of course - why do we create technical debt at all? Can we make high-quality software from the very beginning?
From the developer's point of view ... almost every developer wants to create a great product, and hardly anyone wants to be the author of a second-rate code. So how is it that we give out low-quality code without such an intention? There are several reasons for this.
I recall that Surrey from the University of Tokyo (?) Conducted an extremely interesting study in Finland. Among the Finnish developers conducted a survey: where, in their opinion, there is a technical debt. Suddenly, but no one cited "deadline pressure" as a reason! Also, no one complained about ignorance of technology. Respondents answered either “We did not fully understand the requirements, in general, we did not understand the subject area, so technical debt comes from a poor understanding of the requirements”, or claimed that the architecture was bad, or the architectural ideas were poorly communicated to developers, and this was the main cause of technical debt.
Wolf : This is quite interesting, because once I also thought that technical duty should be avoided, but architecture , above all, leads to technical debt. Then I asked myself: what, in practice, determines the difficulty of software change? And my answer was "tests." If you imagine that I need to choose between a system with a bad architecture, but a lot of tests and a system with a good architecture, but without tests, I would choose the first option.
Again, this is one of those questions that make me doubt the definition of technological debt. I just do not know the exact answer. In principle, one could consider architecture as a part of it.
Johan. Yes, it's hard to say. I recently heard that Philip Krachten , the inventor of the RUP methodology , known for many publications on architecture, says: even if you have a lot of tests, but a mediocre architecture, you cannot hope that refactoring will improve the quality of your system. Because if the architecture is wrong, refactoring will not help you. You need to rebuild the system
Wolf This question can be a subject of long discussion.
(...)
Wolf : And the next question, of course: is it possible to create a system free from technical debt? You wanted to tell about it, right, Sven?
Johan : Is it possible to get a system free from technical debt? I often see headlines like “Ending technical debt!” And “How to become free from technical debt in 10 steps” (or doing something else). I think it is simply impossible to get a system devoid of technical debt. We must come to terms with its existence, that technical debt will always be. Even if you assume that you have achieved this goal and eliminated all technical debt, this would mean that you had to invest a large amount of money and time in tasks not related to the success of the project.
Wolf : The main thing that we can learn from this situation is that the original implementation of Twitter and other products that have achieved outstanding success had a large amount of technical debt. Technical debt has no direct connection with commercial success. (...) Perhaps technical debt is not the best metaphor precisely because it is impossible to pay it entirely. Also, in some cases, technical debt is not a consequence of a conscious compromise, and in some cases it arises due to the emergence of new technologies. Felix Müller , in his dissertation, tried to work out a replacement for this concept. He suggested using the term “Quality Improvement”.
Johan : "Improving Quality" or "Investing in Quality"?
Wolf : Boost. Although we can also talk about investments. The idea is that, since technical debt is always present, and there is always something that can be improved in terms of domestic quality - why not talk about investing in quality? Suppose we spent 5 days processing the testing system, this is an investment. If it saves us a day or two for every next sprint, this is income. Income is calculated, quite simply, as increased productivity minus the cost of improving quality. The last thing I want to point out is that the well - known quality model SQALE is built around roughly the same ideas. (...)
The main argument of criticism addressed to this approach, and not only, is that "Developers are obliged to maintain high quality in all cases!" . I am sure that the efforts of developers alone cannot be maintained. Investments in quality must be coordinated with product management and many other processes. For example, the organization of continuous deployment is a large amount of work that the developer cannot simply perform at will; he must convince the management to do this, and here the “Investment in Quality” metaphor looks quite appropriate: along with the process of continuous deployment, we will have better quality, fewer defects, better proactivity, and so on. I am sure that you, as a developer, are fully entitled to discuss these issues with the management, and that this is capable of moving you towards solving.
(...)
WOLF : Great. We have not considered the question of how it is possible to identify technical debt. Did you have any ideas on these topics?
Johan :
Wolf : If you are tracking (or want to track) the quality of your code, you should get a utility that can do many things: perform code analysis, coverage analysis and much more. The results of this analysis give you a very good idea of ​​the quality, and also creates an array of historical data so that you can understand whether the quality of the code improves or deteriorates over time. (...)
Wolf : What kind of technical debt measures are possible at all?
, , , . , , . . , – – , , . , , , .
: – ( ), . , , , .
, , . « , », , . , , - , . – . . , , « ». - . , , . , , , .
: , – . , . : « , , » — . : « , , ». , , , , , , « , - , ; , » — , , : «! , , , – – , ».
: , . , , -, , . , , . , , – . , , , , , . . , , , .
: , , , . , – , . , , .
: , – . , , , . , . – , , – - , . , , , .
: . , «Pattern-oriented software architecture» : « : ?». , ; , . : «. . , ?» .
, , , .
: . , ?
: . , . , . , , . !
I bring to your attention a translation of an interview published in the Software Enginering Radio podcast in April 2015. Sven Johan and Eberhard Wolf discuss the internal and external quality of the software, recall the generally accepted quality models and strategies aimed at maintaining the internal quality of the software. Technical debt is mainly considered in the context of managing software projects.
Content
Wolf : So, the next release of Software Engineering Radio . This time, we will look at a single topic in the format of a classic interview. My guest is Sven Johan. He and I are co-authors of articles on the topic of technical debt, so that our thoughts, in many respects, coincide. Before we start, Sven, tell us about yourself?
Johan : My name is Sven Johan , I am a software developer at TRIFORK MCDM. I also participate in GOTO conferences, and I had the honor of holding the Microservices mitap.
WOLF : Sounds interesting. Well, my name is Eberhard Wolf , I am a freelance consultant, head of the advisory committee at Adesso AG, a speaker at German-speaking conferences, at the GOTO conference and at several others. I am also the author of the book on continuous software deployment. So, go to the topic.
')
What is technical debt
Technical duty, no doubt, is associated with the characteristics of software quality. Therefore, it is worthwhile to first briefly recall first the theme of quality. Software quality is of two types: internal and external. The external quality of the software is exactly what the user or customer feels. This may be performance, there may be other qualities like security, stable operation, scalability, and so on. The external quality of the software can be assessed or measured objectively. It is part of the commercial value of the product, and it should be the focus of attention on the product and non-technical guidance.
The more difficult part to understand is the inner quality . Internal quality can only be assessed by developers and technicians; This includes everything that makes support and code development easier or harder. Tested this or that functionality, or flawed? Do tests provide easy code changes? Does the project benefit from good architecture, or is it experiencing architectural problems? This also includes the quality of the code, which may be too complicated or too simplified. The fact that this part is not visible from the side, complicates the situation. If you are not a technical specialist, it is difficult for you to assess the internal quality of the software and understand how it affects the development process.
How do you understand “technical debt”, Sven?
Johan : In principle, technical debt is a metaphor, which means a code with significant flaws. We compare technical debt with financial debt in order to clarify the considerations of the internal quality and technical risks of a software project to people who are not technical specialists. Nonspecialists rarely understand the difference between bad and good code. For them, it looks like “The product works, and it's great! Why should I invest in quality? ”
The term “Technical Debt” allows us to clarify that if we want to build something on the basis of a code with significant flaws, this will significantly increase the cost of project development in the future, including the expansion of functionality. In addition, a low internal quality will sooner or later manifest itself externally, and this must be understood. Poor quality code not only slows down the addition of functionality, but also can lead to the manifestation of a large number of bugs. As a result, it hinders the team so much that it becomes impossible to contain internal problems once - and they become problems for users, customers, and other interested parties.
In fact, technical debt is a problem of the scale of the company, and not an internal question of developers. There are cases when, due to a large technical debt, the engineering division of the company stopped entirely. I believe a lot of companies have had experience with 30-year systems in which making even a minor change is almost impossible.
Wolf : Yes, it can be argued that technical debt is one of the key factors affecting the commercial success of software. The term “technical debt” was proposed by Ward Könningham in 1992. Here is a quote:
“The supply of raw code is like a loan . Small loans accelerate the development of the project as long as they are paid on time, and the cost is rewriting. The threat arises at the moment when we stop paying debts. Every minute spent on a code with significant defects is the payment of interest on the loan. An entire organization can be paralyzed under the weight of debt generated by an ill-conceived implementation — be it an object-oriented implementation or some other. ”
As you can see, the metaphor directly mentions financial debt. It refers to the acceleration of supplies by borrowing; subsequently, you are forced to either repay debts or pay “interest”, which is manifested in the fact that your proactivity disappears, and the development slows down significantly. As Sven said, this metaphor is good for speaking with management, as they usually think in economic terms. That was the original definition. But there is an alternative definition, isn't it, Sven?
Johan : Of course. The scientific community rather prefers the definition of Steve McConnell . He formulates as follows:
Technical debt is an approach to designing or constructing over a short period of time, which due to the creation of a technological context leads to the fact that pending changes turn out to be more expensive than immediate ones, including the creation of overhead costs in the development process.
I think this definition is more widespread. This is what we usually mean when we talk about “technical duty”: we do something quickly and ugly, getting immediate benefits - however, we know that in the long run this will hurt us.
Is technical debt really bad
Wolf : So we discussed the definition. But I think the most important thing is the actions you can take regarding technical debt, since it is one of the key factors for a successful business.
The first question, perhaps, is this: is technical debt really bad? If you think borrowing is not such a bad thing. If you bought a house on credit, you can no longer pay the rent; in the end, you will be left with a profit, so that such an investment can be profitable. For the same reason, industry is attracting loans to purchase more productive equipment that provides more output and more income. However, if you spend borrowed money to buy luxury goods, or gifts for the New Year, this could be a bad idea. In this case, the money is not invested, but spent without the possibility of their return.
Again, the metaphor suggests that the payment of debts does not always make sense. Why is that? Because, unlike a cash loan, you pay interest only if you change the code. The internal quality of the code is reduced to the possibilities of its change. And if the code is not subject to change, technical debt may not bother you. In fact, it is pointless to pay "debts" for those parts of the product that do not change.
There is another reason to forget about technical debt, because of which software development sometimes resembles the game “Minesweeper”: a person who has to pay debts is not necessarily the same person who creates them. If, in your case, one team is creating the product, and the other is supporting the product, then the first team is free from “interest payments”. In this case, the practical interests of the first team completely allow for the creation of a huge technical debt for rational reasons, since this can shorten the delivery time. This phenomenon must be remembered when we talk about the problem of technical debt. If you ignore it, it can cause confusion.
Technical debt as a strategy
Johan : Yes. In a recent discussion, we’ve got to the point that technical debt is, in fact, a strategy. Why strategy? Because we can quickly achieve business goals in such a way, knowing that, for example, it is much more important to enter the market as soon as possible, rather than write a perfect code and be late. We may be the first among competitors or even the first in this area.
It is noteworthy that, for example, Eric Ric gave some data on this issue. In his book, he writes:
When I worked in startups, I always felt the joy of writing perfect code. But in the end, this code turned out to be unclaimed. It is much better to quickly create something that can be presented to the user in order to understand whether someone needs our product at all. And, if the user is found - fine, then we can pay our technical debt. But if we spend strength on a quality code, not knowing whether it will be useful, it is generally a waste of time.
About a year ago, Henrik Nyberg from Spotify wrote a post on the same topic, where he said: “In general, we consider the perfect code as a waste of power, if we have no reason to believe that the functionality created by it will be really useful.” They extremely quickly develop functionality. The result is not perfect, but it is shown to the user. And if it turns out that the user likes it, and if it is intended to further develop this part of the code, they will refactor the code, bringing it to a normal state.
As we can see, uncomplicated strategies, applied over and over again, can be associated with such well-known success stories as Amazon and Twitter . As for Twitter, it seems that they are continuously rewriting the system. At the very beginning, Twitter was a Ruby on Rails application, and now it is an instant messenger. Amazon is also very different from what it was at the very beginning. I think these are all manifestations of strategy.
Wolf : That's right. If we talk about Amazon, one of the chapters of The City of Amazon (?) Tells us that at the very beginning, Amazon was a huge, monolithic application that was very difficult to maintain; and when the author of the book joined the company, the entire code was completely rewritten. One result of this refinement is beautiful architectural solutions known as the Amazon Cloud . It is important here that if Amazon were created with thoughts about high software quality and excellent scalability, it most likely would not have survived, as the team would not be able to create the functionality with the speed required. This is a great example of how a software product can be completely rewritten due to technical debt, but it turns out to be incredibly successful.
Johan : I think it was the same with Twitter, because initially they had no idea how many users they should count on. There is a significant difference: do you expect a thousand users, or a million, or one hundred million; but you still need to start somewhere.
Technical duty and architecture
WOLF : By the way, I would definitely mention this point in a situation where I would have to talk with software architects. I noticed that they too often raise scaling issues. It seems that software scalability is their main concern, while it would probably be better for them to focus on time-to-market . Otherwise, they have every chance not to see the moment when scalability is needed, since by that time the company may go bankrupt or the estimated source of profit will disappear.
As you can see, poor scalability is not always bad either. However, technical debt you somehow need to control. One of the best ideas I've come across belongs to Eric Evans . Evans is known as the author of the book Domain-Driven Design; and while one part of his approach regarding the use of uniform terminology, repositories and the like in a team is widely known, there is another part with which few seem to be familiar with. This is part of strategic design and design at the level of large-scale structures.
The essence of his idea is as follows: first of all, you cannot have the same quality of code in all parts of your system (generally speaking, this is a rather obvious point, if only because different team members differ in different quality of code; and even the best team is not homogeneous). What to do? Although you could just leave to chance, which parts of your system will be written well and which parts will be bad, it is better to make a conscious decision. One way to cope with technical debt is to ask yourself the question “Which parts of the system are really important, given current and future changes?” The answer can be found by examining the history of changes or looking at the subject area: which parts of the system will give us a competitive advantage if we Will we be able to quickly refine them? If, for example, delivery methods are very important for your store, it is reasonable to set a goal so that the part of the code responsible for this functionality has high internal quality. Evans, in his book, reviewed quite a few templates relating to this. The best of his ideas is that you can have boundaries between contexts, each of which gives a greater or lesser importance to a certain aspect of the subject area, and then between these contexts you can create a “protective layer”.
By applying this approach to the problem of internal quality, you could create a part of the system - in our example, responsible for the delivery of goods - with a really high-quality model of the domain where the quality and complex code is located, and the second part of the system, for example, responsible for interaction with the customer. in which parts of the code that are distinguished by low quality and mediocre modeling will “temporarily” dwell. To ensure that bad models do not affect your priceless delivery system, you create a protective layer that separates the two parts of the system and translates calls between them. Using this approach — I apply the “cell” metaphor for it, just like the cells of a living organism — you save each of the cells from penetrating external problems. This is a pretty good way to strategically manage quality and technical debt. You maintain some parts of the system at the highest level, constantly monitoring the quality, while for others you use standard, purchased or obsolete components. It seems to me that when developing fairly complex systems, this strategy deserves attention.
Is it possible to avoid technical debt?
Johan : One of the well-known questions, of course - why do we create technical debt at all? Can we make high-quality software from the very beginning?
From the developer's point of view ... almost every developer wants to create a great product, and hardly anyone wants to be the author of a second-rate code. So how is it that we give out low-quality code without such an intention? There are several reasons for this.
- The most obvious reason is, of course, the pressure of deadlines: we want to do something well, but there is no time. We have to do a release, we have a didline. Therefore, in order to work quickly, we have to make compromises in the field of quality. We test superficially, we do not write automated tests, we do not think deeply about our technical solutions, and as a result we get a mediocre result most of the time.
- The second reason is the lack of knowledge of technology details. If we use something for the first time, having only a basic understanding, we inevitably use it incorrectly, albeit with the best of intentions.
- The third reason is that imperfect knowledge of the subject area gives rise to strange architecture and data models.
- And finally, there is the phenomenon of "software degradation" over time. A system that could be considered perfect 15 years ago, like EGB2.0, will look outdated today.
I recall that Surrey from the University of Tokyo (?) Conducted an extremely interesting study in Finland. Among the Finnish developers conducted a survey: where, in their opinion, there is a technical debt. Suddenly, but no one cited "deadline pressure" as a reason! Also, no one complained about ignorance of technology. Respondents answered either “We did not fully understand the requirements, in general, we did not understand the subject area, so technical debt comes from a poor understanding of the requirements”, or claimed that the architecture was bad, or the architectural ideas were poorly communicated to developers, and this was the main cause of technical debt.
Wolf : This is quite interesting, because once I also thought that technical duty should be avoided, but architecture , above all, leads to technical debt. Then I asked myself: what, in practice, determines the difficulty of software change? And my answer was "tests." If you imagine that I need to choose between a system with a bad architecture, but a lot of tests and a system with a good architecture, but without tests, I would choose the first option.
Again, this is one of those questions that make me doubt the definition of technological debt. I just do not know the exact answer. In principle, one could consider architecture as a part of it.
Johan. Yes, it's hard to say. I recently heard that Philip Krachten , the inventor of the RUP methodology , known for many publications on architecture, says: even if you have a lot of tests, but a mediocre architecture, you cannot hope that refactoring will improve the quality of your system. Because if the architecture is wrong, refactoring will not help you. You need to rebuild the system
Wolf This question can be a subject of long discussion.
(...)
Wolf : And the next question, of course: is it possible to create a system free from technical debt? You wanted to tell about it, right, Sven?
Johan : Is it possible to get a system free from technical debt? I often see headlines like “Ending technical debt!” And “How to become free from technical debt in 10 steps” (or doing something else). I think it is simply impossible to get a system devoid of technical debt. We must come to terms with its existence, that technical debt will always be. Even if you assume that you have achieved this goal and eliminated all technical debt, this would mean that you had to invest a large amount of money and time in tasks not related to the success of the project.
Wolf : The main thing that we can learn from this situation is that the original implementation of Twitter and other products that have achieved outstanding success had a large amount of technical debt. Technical debt has no direct connection with commercial success. (...) Perhaps technical debt is not the best metaphor precisely because it is impossible to pay it entirely. Also, in some cases, technical debt is not a consequence of a conscious compromise, and in some cases it arises due to the emergence of new technologies. Felix Müller , in his dissertation, tried to work out a replacement for this concept. He suggested using the term “Quality Improvement”.
Johan : "Improving Quality" or "Investing in Quality"?
Wolf : Boost. Although we can also talk about investments. The idea is that, since technical debt is always present, and there is always something that can be improved in terms of domestic quality - why not talk about investing in quality? Suppose we spent 5 days processing the testing system, this is an investment. If it saves us a day or two for every next sprint, this is income. Income is calculated, quite simply, as increased productivity minus the cost of improving quality. The last thing I want to point out is that the well - known quality model SQALE is built around roughly the same ideas. (...)
The main argument of criticism addressed to this approach, and not only, is that "Developers are obliged to maintain high quality in all cases!" . I am sure that the efforts of developers alone cannot be maintained. Investments in quality must be coordinated with product management and many other processes. For example, the organization of continuous deployment is a large amount of work that the developer cannot simply perform at will; he must convince the management to do this, and here the “Investment in Quality” metaphor looks quite appropriate: along with the process of continuous deployment, we will have better quality, fewer defects, better proactivity, and so on. I am sure that you, as a developer, are fully entitled to discuss these issues with the management, and that this is capable of moving you towards solving.
(...)
Identification of technical debt
WOLF : Great. We have not considered the question of how it is possible to identify technical debt. Did you have any ideas on these topics?
Johan :
- Technical debt may be explicitly designated, such as code, full marks TODO and FIXME . This code means that developers were in a hurry to put, for example, functionality, and some TODO could mean: “Hey, we should take the configuration out of the code!”, Or FIXME with the meaning “It works only in 95% of cases; if we really need this functionality, this place needs some work. ” Such cases, in my opinion - the simplest.
- There are more serious situations. For example, you want to make a change to the code, and one after the developer says: “Oh! I can't change this code, Kat wrote it! ”. This means that you are in serious trouble, because because of your desire to speed up development, it turned out that only one developer has the knowledge necessary to complete the task. They were not transferred to the team; this is an island in the sea; and if this developer gets under the bus , no one can continue the development of this code. Generally, if someone says "This code can only be changed by that person," this is a clear sign of a big technical debt.
- Also, it’s bad if you happen to hear “Oh, we already have similar functionality elsewhere, let's copy it with a few changes” - you can, of course, do this, but if you abuse it, your codebase becomes completely unsuitable for support
- A similar situation is when a developer says “Well, I don’t want to change this place at all, because I don’t have complete confidence. If I change the code here, most likely, a lot of things will break. ” This situation means that the application is designed really badly, so much so that you cannot make local changes, because everything is connected to everything and looks like a plate of spaghetti; and you risk completely losing the development pace, since any new requirement, in fact, will cause the appearance of new software defects that can be overcome only by intensive testing.
- You may also have quantitative indicators, such as Velocity on the Scrum team. If the development speed indicator falls hopelessly, while the team is quite stable, you should analyze the reasons for this. The most likely cause of the fall is also technical debt.
- It should be remembered about aging software. Old libraries, old technologies, anything old - even if you built a perfect system, in 10 years it will be outdated and additional efforts will be required from you. You will be updating libraries, or even replacing them with others, in order to be able to do what you need to be able to do in, say, the year 2015.
- It's also bad if you happen to hear something like “Oh, we can't fix this bug immediately. Yes, this is just one line, but the transfer of the production system will take a week or two. ” You need to strive to be able to deploy the patch in ten minutes, or maybe in an hour. Two to three weekly deployment cycles are a problem. And more (although it is less important): if your tests are performed for a really long time, then this leads to serious time costs. And if your rules require you to fix only the code that passed all the tests (I'm sure it should be that way), then it is very important: do the tests run in a minute, or do you have to wait ten minutes, or twenty.
Wolf : If you are tracking (or want to track) the quality of your code, you should get a utility that can do many things: perform code analysis, coverage analysis and much more. The results of this analysis give you a very good idea of ​​the quality, and also creates an array of historical data so that you can understand whether the quality of the code improves or deteriorates over time. (...)
What can be done?
Wolf : What kind of technical debt measures are possible at all?
- One of the ways you can take advantage of this is buffer tasks and pre-releases . You say: "Let's allocate time for the team to work on technical issues in order to improve the quality." These may be technical releases that have the sole purpose of improving the code base. , , , , « », ; , , , , .
- . « » , , ; , , : «, , » . : , « ». ? , , . , , . , . : «, , - ».
, , , . , , . . , – – , , . , , , .
: – ( ), . , , , .
, , . « , », , . , , - , . – . . , , « ». - . , , . , , , .
: , – . , . : « , , » — . : « , , ». , , , , , , « , - , ; , » — , , : «! , , , – – , ».
: , . , , -, , . , , . , , – . , , , , , . . , , , .
: , , , . , – , . , , .
: , – . , , , . , . – , , – - , . , , , .
?
: . , «Pattern-oriented software architecture» : « : ?». , ; , . : «. . , ?» .
- : «» . , , , , , , – , , . , , , , . , .
- – «» . , , – . , 30 . , . , – . , , . , « » – , – .
- , , – , – , . , , – . , – , . , : , , , , ?
, , , .
: . , ?
: . , . , . , , . !
Source: https://habr.com/ru/post/292644/
All Articles