Managing technical debt
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 106 | |
| Number of Parts | 169 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/21196 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 2016106 / 169
1
5
6
7
10
11
12
13
18
20
24
26
29
30
31
32
33
36
39
41
44
48
51
52
53
59
60
62
68
69
71
79
82
83
84
85
90
91
98
99
101
102
106
110
113
114
115
118
122
123
124
125
132
133
135
136
137
140
143
144
145
147
148
149
151
153
154
155
156
158
162
163
166
167
169
00:00
Data managementBitSoftware developerCodeInteractive televisionMeasurementWritingMultiplication signRight angleInclusion mapComputer animation
01:38
Presentation of a groupLevel (video gaming)Data typeSoftware developerSpring (hydrology)Presentation of a groupLevel (video gaming)Multiplication signParallel portProjective planeType theorySinc functionComputer animation
02:53
Computer programmingTerm (mathematics)Finitary relationDirected setCodeDecision theoryCartesian coordinate systemTerm (mathematics)Constraint (mathematics)Multiplication signSoftware developerMultiplicationMassMereologyWritingInterface (computing)Cartesian coordinate systemVideo gameDecision theoryReal numberSoftware design patternRight angleCodeComplex systemMetropolitan area networkStack (abstract data type)Buffer overflowComputer animation
07:14
Cartesian coordinate systemStatement (computer science)Software developerMultiplication signMereologyDifferent (Kate Ryan album)Decision theoryComputer-assisted translationPrincipal idealMathematicsPattern languageCartesian coordinate systemCodeData managementReal numberComputer animation
10:11
Level (video gaming)CodeCodeDecision theoryBitPresentation of a groupBridging (networking)CausalityInterface (computing)Computer animationLecture/Conference
11:30
Level (video gaming)CodeLevel (video gaming)Software testingSoftware frameworkBitFunctional (mathematics)Cartesian coordinate systemSoftware developerLine (geometry)MereologyMultiplication signWhiteboardRight anglePoint (geometry)Graph (mathematics)Disk read-and-write headCodeQuicksortMathematicsDataflowBlock (periodic table)Type theoryDecision theoryDrop (liquid)Machine codeFigurate numberLecture/ConferenceComputer animation
15:59
ArchitectureLevel (video gaming)Computer architectureLevel (video gaming)Decision theoryCodeScaling (geometry)Cartesian coordinate system10 (number)Moment (mathematics)Thread (computing)Computer configurationObject (grammar)Data storage devicePoint (geometry)Computer simulationBitQuicksortFile systemEndliche ModelltheorieGodLatent heatLocal ringProjective planeWorkstation <Musikinstrument>DatabaseData modelDistribution (mathematics)Right angleInstance (computer science)Lecture/ConferenceComputer animation
19:17
Level (video gaming)CodeArchitectureMeasurementProjective planeSoftware bugComputer architectureLatent heatMultiplication signCartesian coordinate systemPhysical systemResultantLevel (video gaming)Product (business)Set (mathematics)Point (geometry)Decision theoryCodeQuicksortData managementSound effectCellular automatonNetwork topologyBitIntegrated development environmentClosed setState of matterComputer animation
23:18
CodeArchitectureOnline helpScale (map)Maxima and minimaTelecommunicationJoystickComputer programmingMaxima and minimaOnline helpDifferent (Kate Ryan album)TelecommunicationProof theoryProduct (business)Latent heatLine (geometry)NumberCartesian coordinate systemInterface (computing)Profil (magazine)Dependent and independent variablesWordBuildingNumeral (linguistics)JoystickRing (mathematics)Scaling (geometry)Context awarenessProjective planeSoftware testingLevel (video gaming)Arithmetic meanRight angleInternet service providerVideo gameComputer animation
28:09
TelecommunicationSystem identificationPrincipal idealSoftware testingImplementationMultiplication signMereologyResultantRight angleInterface (computing)CollaborationismCodeCartesian coordinate systemCore dumpProduct (business)MathematicsCellular automatonDependent and independent variablesPerspective (visual)TelecommunicationForceDecision theoryPlanningControl flowMultilaterationLecture/ConferenceComputer animation
31:09
SoftwareBoundary value problemTelecommunicationSystem identificationPrincipal idealSoftware testingMereologyPresentation of a groupLine (geometry)Fitness functionLimit (category theory)Metric systemLibrary (computing)SoftwareProjective planeCartesian coordinate systemMainframe computerParameter (computer programming)Computer fileOpen sourceBoundary value problemState of matterMultiplication signSoftware bugInstance (computer science)Subject indexingOptimization problemType theoryPosition operatorRight angleDecision theoryProduct (business)Event horizonLinear regressionImplementationTelecommunicationResultantMeasurementCASE <Informatik>CodeDataflowDifferent (Kate Ryan album)Point (geometry)AbstractionDirection (geometry)Term (mathematics)Interface (computing)Default (computer science)Network topologyCore dumpClient (computing)Process (computing)PixelModule (mathematics)Mathematical analysisError messageGroup actionContext awarenessSoftware developerFreewareComputer configurationGoodness of fitPrice indexTranslation (relic)Sinc functionLecture/ConferenceComputer animation
40:50
SoftwareBoundary value problemMultiplication signCartesian coordinate systemHand fanLevel (video gaming)Proof theorySummierbarkeitMaxima and minimaBitTelecommunicationTerm (mathematics)Information systemsUnit testingLatent heatAnalytic continuationControl flowPoint (geometry)Software maintenanceFigurate numberSoftware testingFrame problemDegree (graph theory)Set (mathematics)Touch typingCircleEndliche ModelltheorieRule of inferenceINTEGRALDampingPhysical law1 (number)RootMereologyCuboidPhysical systemCodeOrder (biology)Query languageLine (geometry)Dependent and independent variablesProcess (computing)Linear regressionMathematicsDifferent (Kate Ryan album)AutomationProjective planeView (database)FamilySimilarity (geometry)VirtualizationRight angleType theorySoftwareBuildingElectronic visual displayDecision theoryFeedbackSystem callStandard deviationGoodness of fitStaff (military)Web 2.0DataflowEntire functionSuite (music)Functional (mathematics)Software bugContinuous integrationCode refactoringAsynchronous Transfer ModePlanningLecture/Conference
50:15
Software testingConstraint (mathematics)TelecommunicationComputer architectureMereologyLevel (video gaming)Projective planeHeegaard splittingOperator (mathematics)outputDecision theoryNegative numberDataflowFunction (mathematics)Process (computing)Cartesian coordinate systemOpen sourceType theoryPerfect groupComputer programmingLibrary (computing)CodeElectronic mailing listInstance (computer science)Constructor (object-oriented programming)Line (geometry)Different (Kate Ryan album)DatabasePattern languageProgrammer (hardware)Software developerControl flowView (database)Dependent and independent variablesLimit (category theory)Context awarenessSelf-organizationSingle-precision floating-point formatFormal verificationService-oriented architectureExtreme programmingNetwork topologyPhysical systemDescriptive statisticsNatural numberComputer fileForestInheritance (object-oriented programming)Power (physics)ProteinScripting languageComputing platformLocal ringScatteringSlide ruleAddress spaceCountingOntologyEndliche ModelltheorieRule of inferenceMultiplication signTask (computing)Optical disc driveLecture/Conference
59:39
Red HatDemonIntegrated development environmentSoftware bugComputer animation
Transcript: English(auto-generated)
00:00
Hello, everyone. We're going to have Mircea Zeta talk to us, actually start an interactive session about managing technical debt. So questions are welcome, I believe. It's supposed to be interactive. By the way, this is the first interactive session ever
00:20
done at any EuroPython. So hey. As my colleague mentioned, this is the very first interactive session that is on EuroPython.
00:40
I feel a little bit like a guinea pig, but that will pass. We should have a discussion here. That's what I understand. So I also have some slides. And we'll see how this works. A few things about who I am. I am technical manager at Spice. We're a small company located in Cluj, Romania.
01:02
And we're doing mostly Python development work. For those of you who wonder what the technical manager does, well, we are the people who pretend we can still write code. So that's mostly about it. The talk itself is about managing technical debt.
01:21
When I started thinking about the subject, I realized that is pretty much like politics or religion. Everyone has an opinion, so that includes myself. So the more opinions, the better. And since I mentioned that is religion, we're going to start with a very beautiful impressionist
01:41
picture. Our colleagues from classic paintings named this something around developers asking forgiveness for technical debt at the beginning of a sprint.
02:00
That pretty much describes it, to be honest. OK, in summary, what we're going to try to do, we're going to try to define the purpose of the presentations that set the stage. We're going to see some short history about the subject itself. We're going to see where exactly the technical debt occurs at which levels.
02:21
What are the consequences? Let's talk about interest, and also about the type of projects where you actually care about technical debt. I'm not saying that you shouldn't, but there are projects where you care more or you care less. All right, first of all, since it's an interactive
02:40
session, we have one hour. I would like to somehow limit the time for discussions per subject at about one or two minutes, depending on the interest. And by the way, seeing the lineup, what's in parallel with this talk, there's really many sinners around here. So, OK, what is technical debt, first of all?
03:02
It was first defined by Ward Cunningham, and it was defined in the early 90s as a metaphor, more or less, in terms of describing the extra development work when we choose easy, short-term solutions against longer-term or the proper way to implement stuff.
03:21
It is a metaphor because it's released directly to the finance industry, to loans, and we're gonna go and see what exactly is the debt and the interest that I mentioned earlier. There are multiple ways. People have multiple opinions about what technical debt means and what it should mean,
03:41
what it is. One of those people is Bob Martin. I'm sure you guys all heard about Robert Martin. Technically, he says that messy code is not really technical debt, that's just a mess. Now, towards this purpose, he says
04:01
that when you make a conscious decision about technical debt, what should happen is that you should try and write even cleaner code, you will have even cleaner interfaces, and so on. Does this work in real life? Why?
04:28
So the answer was that the people usually do it in a rush and don't think about stuff. That's partially true, I think, because when you make a decision that you're gonna have technical debt and you're gonna have to live with it, it's because you have constraints,
04:43
and usually those are time constraints, and the time constraint that's required to write cleaner interfaces and so on, it sometimes works, sometimes it doesn't. Now, next to that, we have Martin Fowler, and this is where we have the discussion if we're talking about conscious
05:02
and unconscious technical debt. His opinion is that the question, if a mess is technical debt by itself, is the wrong question. The idea is that you will have technical debt in the end. So it's more about defining the conscious approach
05:26
and the unconscious approach, and he splits this into what he calls the technical debt quadrant, and I put it here, this is not mine, so it's copyrighted there, and we have the reckless technical debt and the prudent technical debt, and on the horizontal line, deliberate and inadvertent.
05:44
Okay, the reckless one for the deliberate one. We don't have time for design. Of course, what I would like to mention is that these guys are advocates for design patterns, refactoring, writing clean code, right?
06:03
So design is there. The prudent approach for the deliberate part is that we must ship, and we have to deal with consequences. Now, how many of you here were in this situation? Okay, I'll raise my hand as well.
06:23
All right, for the unconscious part, we have the first part of the mess, what is layering. People do not really know what they are doing.
06:42
I saw autocomplete from Stack Overflow. That might cause technical debt in the end. The other part is actually very, very interesting. Now we know how we should have done it. Robert Martin, in the talk that he has,
07:01
he says something like this. If you have a complex system that you haven't built before, you will know how to build it once you've built it, and it's not going to be the way you built it. So that is the other part. It's prudent in the end. You do your best. Now, next part is, why the quadrant,
07:23
why did they approach it in this way, and what can we learn from these three statements? Yeah, and why calling it technical debt? Let's start with the last one. Why do you think they called it technical debt? Yeah, you pay interest in that, correct.
07:40
But why not say anti-patterns? It might look like the right time when you're doing it. Okay?
08:01
Sometimes you can technically borrow strategically, because if you need to ship today, and if you don't ship today, for example, maybe you will not have funding to do anything anymore. So you can strategically borrow, and then it's not an anti-pattern, it's actually, it could be a good thing to do. But at the end of the day, what's the difference between technical debt
08:21
and an anti-pattern? Baseline. You can try to avoid technical debt as well. Not always with anti-patterns also.
08:40
Well, it's easier to discuss with business people. Because if you go to a business owner, someone who is a development manager, or who doesn't really have his fingers into the development world, if you're going to him and you say, okay, we have anti-patterns here, or we have any other kind of terminology, or whatever, it doesn't mean anything for them.
09:01
It means, okay, it works, why? Why change it? Why fix it? Technical debt, on the other hand, as you guys already said, directly relates to the finance part. So when you have a technical debt, you have two parts, you have the principle and you have the interest. This, they don't understand. This we all understand, because we make a conscious decision to take a loan,
09:23
and we know we have to pay off the principle, we have to pay off the interest. And all the three approaches that I presented are ways that people unconsciously, basically look towards advocating what they stand for. And yeah, this is the same with us.
09:45
Okay. In my opinion, technical debt is a status quo. It's there, it's either there or it isn't, and it's no real philosophy around it. It's not something that you might or you might not have.
10:01
I used to describe this as more as a Schrodinger's cat problem. Before you acknowledge it, you both have it and you don't. But it's a matter of acknowledging technical debt. So once you acknowledge it's there, it actually exists.
10:20
So once you acknowledge it, don't live in denial. Whatever. Now, questions or comments? It depends how you, the question is if there is any code
10:41
that does not have technical debt. It depends how you look at it. It depends how you look at it, to be honest. Does it cause you problems later on? Did you make a conscious decision that you're gonna have it? Will you be able to cross that bridge once you're there?
11:04
How well is your code tested? How clean are your interfaces? You cannot have something specific, and I would like to come back a little bit at the purpose of the presentation. I don't have all the answers. I don't think I have all the questions.
11:21
That's why we're here and was trying to have a discussion around it. But being the first session at the Eurofaton that's interactive, we have a lack of microphones also in the room. So Radu is doing his best. Okay, at what levels does technical debt occur? I already put that up there. The first level that I see, it's at code level,
11:42
and this is what you mentioned. How does technical debt at code level manifest itself? Yes? Missing test, careless coding.
12:04
Careless development where you have to ship a feature as soon as possible, and you miss a lot of best practices, so spaghetti code. Okay, very good.
12:23
A framework that you depend on that becomes deprecated. The question is a little bit larger with the framework because every framework will solve parts of your problems. So when you choose a framework, it's also a type of technical debt. It will take you 80% of the way. It does depend how much you have to spend
12:41
for the rest of the 20%. So that's another approach. But let's say that you have, your code consists of something like 300 lines of code of undocumented functions. So you have functions or methods that are like 300 lines of code. What is the technical debt that you see there?
13:07
Why? Why is there technical debt? Why the documentation is missing? Why is there technical debt? Correct, it will save you time.
13:20
So that's a debt. Something else? To make decision on this kind of drop it at some point.
13:41
Readability, mostly. Okay, something else? That's true. Okay, how would you test an application
14:02
that has functions or methods that are 300 lines of code long? You don't want tests in such code, right? No, you do, but you do. That's true. Okay, so people who write 300 lines of functions
14:23
do not have tests. Okay, we have the principle defined here from our technical debt. Once, as our colleague said, we're gonna have to go back and figure out, every time that we have to change the code, we have to figure out what we wrote in there because it's undocumented.
14:41
For this part, we have the interest that also colleague here mentioned in regards that when you have to outsource to someone else, they will not understand the code. But how about ourselves in three, six months time? Every time that you have to revisit that function, that is no longer technical.
15:02
That is already interest. Every time that you have to onboard someone into an undocumented code, that's no longer technical. That is interest that you pay. Every time that you change the functionality within the test, within the function, the test will have to be updated.
15:20
That is principle at one point and the interest from that point on. So this is one example of technical debt that can occur at code level. What's the impact? How would you see the impact at code level? Is it high, is it low?
15:41
High? I think it's the simplest thing to change. Yeah. If you have broken API and a lot of code depends on it, yeah, that's true. But that is one step further about the broken APIs.
16:03
We're talking about technical debt at the architectural level. If you have broken APIs and you cannot maintain your code when you change it, that's an architectural decision and you have technical debt at an architectural level. Now, at this point, I see two subdivisions.
16:22
Application level, what you mentioned, infrastructure level. I worked on a project and at a specific moment, I made a decision about the data model and some colleagues here in the room already know it and had to live with the pain. They're booing.
16:40
Okay, that was the wrong decision. That was a decision that I had to take at an architectural level and we paid a lot of principle, we paid a lot of interest, people working on that application still paid interest. Yes, Andrei. That's a bad decision. Would I do it again?
17:02
Probably not. Right now, I'm working on an application with a similar problem where I have the feeling that it might go the same way. I don't know how to fix it. It's still data model related. Okay, what's the impact at the architectural level compared to the code level?
17:21
If you mess up the architecture, what do you pay? You can't scale. Maybe you can, maybe you can't. It depends. What kind of scaling? How can you scale?
17:41
You cannot scale horizontally if your architecture is broken, but can you scale vertically? Correct. I worked on an application where the only options was to scale vertically because we did a lot of simulations, like tens of thousands
18:00
of simulations, electronic circuit simulations, and we had one big object that all the threads share the same big object and it was mutually exclusive. Now, don't ask why that was not possible to have the distributed. It was another decision. Okay, but going back a little bit, at the infrastructure level, how can you have technical debt?
18:32
Okay, manual setup at the infrastructure? Correct.
18:41
That's one thing. What if your application depends on local storage? Stuff that's on your actual application instance when you have to scale up?
19:01
Yes, and you have to share the same file system or you have to have a distributed storage and so on. It's the same with databases. Okay. The next level is at the specification level. This is what I think what I think. Why is it important to, or why do I think that's,
19:23
why is it important to have the specification level sorted out or the specs sorted out? What kind of technical debt results from specifications?
19:45
Yeah, it really does prevent you to finding the best solution. It has automatically impact on the architecture level. On what do you decide that you do and how do you do it? So once you have a set of specifications, make sure you clarify them
20:01
because if you don't know what you're doing properly, the results can bubble up. Okay, we talked a little bit about interest. We touched the subject before. So at all levels that we discussed,
20:21
we have to pay the interest. We saw that at code level, the amount of interest that we have to pay is relatively low. As we go up to architecture and specifications, we're gonna pay more and more interest. Every bad decision that we make at the architecture level will have a snowball effect.
20:44
Now, one problem that we have while we manage the technical debt is that project manager, product owners, business owners will want to know how can you measure technical debt? How can you measure the interest? Why is this so large?
21:01
How can we measure the interest? Because when we have a finance loan, we have the principle and we have the interest. We know exactly the amount of money that we have to put back. Can we do this in software?
21:21
I would suggest that you would notice that it gets slower and slower to ship features. That's the worst thing. As time goes on, a year later, two years later, it's slower and slower to implement new features. You cannot, it's true, you cannot predict. You cannot say from the start when you say, okay, I acknowledge that I have technical debt. You cannot say what exactly will be
21:41
the interest of this debt. But as time goes by, it is easier and easier for people to see, okay, I have to fix something. It takes a lot of time. When I fix it, the application will break probably in 10 other places. Usually technical debt makes your system
22:01
both rigid and fragile. When you have this, it's not open to change and you can, everything that you deliver, be it new features or bug fixes, take longer and longer. That's one way to measure it. The important thing is that every time that you have this, you probably should discuss
22:23
with the people who own it because you're gonna have questions. Why is this simple fix take so long? Why does it take so long to have this simple fix ship? Why does it take so long to have this fixed issue and have it deployed on a production environment?
22:42
So infrastructure is not ready or we have to do manual stuff. Just a question, isn't that like too late? I mean, if you've already gotten to the point where features take so long to implement, aren't we just now realizing that it's technical debt that's from two years ago? It's a matter of acknowledging it.
23:01
If it takes two years for us to realize that this is technical debt, then we did something wrong at some point. Usually technical, you can notice technical debt a lot earlier than that. But probably it was not communicated properly in the timeline. It really takes you two years to figure out
23:29
should have been the right thing to do at the time, but the requirements changed during the last two years. That is correct. The requirements changed during the last two years. Yep, add that too.
23:46
Cool. We can have more of this. Okay, one question. Who's responsible for technical debt? Everyone. Okay, when?
24:03
Okay, as soon as it's acknowledged. What does it mean that something is everyone's responsibility in a team? Nobody will do it. Exactly. Okay, however, you are correct. Technical debt is everyone's responsibility and when you encounter it,
24:21
the least that you can do is communicate it. The least that we can do is communicate it. The least we can do is start discussing around it. Okay. Now, some things that I think that would have some impact on preventing.
24:42
Search. If you're building something and you don't know how to build it, search for it. If you didn't find the proper solution, ask for help. I encountered the lack of asking for help in numerous occasions and it does lead to technical debt. It has nothing to do with pride or ego
25:02
because in a team, we're all trying to achieve the same thing. Pocket. POC. That's proof of concept. If you don't know how to do it, create a proof of concept. Okay. And that's the line that I put previously.
25:22
Diligence. Do the bare minimum that will allow you to scale at the infrastructure level. Make sure that you have clean interfaces. Your communication interfaces are correct. Be aware of how you're gonna scale, how will you have to scale if it's going to have to be horizontal or vertical.
25:41
It really does depend on your application profile. At the specification level. The very first thing is communication. If you do not have communication, you will not be able to fix technical debt ever. Communicate, make sure that you communicate properly.
26:00
Be aware of how you can and you have to communicate with non-technical people. The second line is when we work on projects, when we start a project, usually we have a few steps. That's POC, POV, and MVP.
26:23
Do you guys know the difference between these three things? POV, proof of value. Proof of value. Well, think about the fact that you're building an application, you own an application, you want to build one. But the market that you're entering
26:41
is not exactly mature, or there is no reference to what you are doing. Okay? You want to be sure that before you start building it and releasing it, you can prove yourself. Now, this is done in a number of ways. You can, from simple mock-ups, clickable mock-ups,
27:00
that will demonstrate the value for stakeholders or for investors, to having an actual application that works, and then you can do something like live testing, that you interact with your user. You analyze and decide if you're moving forward or not.
27:20
It's very important that you know the proof of concept, proof of value, and the MVP. Do not let yourselves pulled into a discussion, something like, this is a proof of concept that ends up in production. Who saw this? I've done it.
27:41
Okay. And, yeah. What is MVP again? Minimum viable product. Yes. Exactly. And do not make assumptions.
28:00
And this is, yeah, and the famous last words are, what could possibly go wrong? Now, what to do when you actually have technical debt? The very first step is to identify it,
28:21
at least in my opinion. Next, know the exact problem, communicate it, and make sure you translate this to cost. Every time you want to fix something, it's cost. It costs money, right?
28:40
Make sure of the cost, not only from the money perspective, but also from the impact of the change that you're doing. If you don't have clean interfaces, if the code that you wrote is used in numerous applications, make sure that you keep your interfaces, okay,
29:03
and you can sustain them. Okay. Again, communication. And from the communication part, what results or should result, it would be a plan to pay out the debt. And this is a discussion sometimes when you build something and it's wrong, you also have a lot of code that's built on top of it.
29:24
So it's a decision that you have to see if you have to pay the principal part, the actual bad implementation, or also the interest, and which comes first. Do you have to fix the code that relies on a bad implementation, or you have to fix the bad implementation first?
29:42
How would you approach it? Fix the code first. Why? It's a dependency. Correct. When you change the core part, it's gonna break everything. You will have to fix everything else.
30:16
So you can be smart about it, fix the interfaces, and keep the bad part
30:25
for later on, right? Okay, yeah. Now, collaboration. Yeah. As we discussed already, it's everyone's responsibility.
30:40
We're all a team. It's our responsibility to fix it. Collaborate. But when I'm discussing about it's all of us as responsible for the code and for the technical debt and for fixing it, I'm not only discussing about the technical team. It has to be a collaboration with product and so on.
31:01
We're all the team. We're all a team. You have to have timelines. You have to have a plan and say, okay, this is how we're gonna fix it. This is how paying off the technical debt and the interest fits within our timelines, our deadlines, and so on.
31:25
And this is actually the last part of the presentation. Did you guys ever hear something like, I don't care about technical debt?
31:40
Literally, like this? Okay. Did you guys hear something like, this is a problem. We acknowledge this. We're gonna fix it later. Sometimes. What's the context when you hear this?
32:03
Sorry? True, business guys usually. But the thing that I saw was that there is a difference between companies and business guys.
32:22
Companies that live out of delivering software are more interested or should be more interested in paying off technical debt. This is not necessarily true for companies for which software is a helper to their business.
32:40
It helps develop things. For them, for the second type of companies, having manual tweaks for two, three, five, six, 10 releases, having someone actually doing something that can be automated, for instance, it's acceptable.
33:03
Pushing it to fix it might not be the right solution. It's a business decision in the end. However, if what you do is actually software delivery, and if you live out of software, that's your core business, then technical debt is something that you're certainly interested in,
33:22
and should be interested in, more than anything else. Too much people are different from their implementation or their infrastructure, or less infrastructure,
33:41
but their application, or their API, things like that. How can you mitigate the technical debt in this case? The question was what about the usage of open source software within applications where you have the technical debt. How can you mitigate what you get, actually,
34:03
because you get it for free. First of all, know what you're using, and try to know the library, the application, or the open source project that you are using. Know its limitations, know its boundaries. This is something that you do at the beginning of a project if you can.
34:20
If you do not do this part of analysis, if you don't take time, it's very likely that at some point you will end up with a lot of technical debt. One thing that I think you can mitigate is once you know what the technical debt is within that project, is try to have an abstraction layer and communicate with your own interfaces for the stuff that you need, if that is possible.
34:43
That will be one solution. If you guys see other solutions. One thing I had to do was actually go in and fix bugs in open source projects we were using because that open source project, since it's the core of my product now, in a way, it's also my code,
35:01
so when I'm using it, it's part of my technical debt, so I have to fix it. Correct, and once you fix it, create a pull request, push it mainstream. Don't keep it for yourself. It might or might not get integrated depending on how active the project is.
35:21
Anything else, any other questions? One sec. And for freelancer or contractors, how they should deal with technical debt when clients doesn't want to pay more for fixing bugs that may be dangerous for him,
35:42
for his project? How do you think we should handle that when we are freelancers? You have to have a very clean way of explaining the technical debt to your customer. You have to be able to have an argument why does this take as long as it take?
36:01
Why do you have to fix it? He has to see the fact that not fixing this will cost him this much, this much immediately, and this much in the long run. Usually it's very hard if you're a freelance developer to make this argument at the very beginning of a project. First thing that you have to do is earn trust.
36:22
And even though some people say that okay, I'm outsourcing your project, I trust you by default, that is rarely the case. Trust is something that you earn and not get by default. Once the client gets to trust you and sees the results of your work, it's gonna be easier and easier for you
36:42
to discuss these kind of issues with him. So it's merely a communication problem and a trust issue. Sir?
37:06
How do I get a dollar measure of my technical debt? You translate it in time, in time spent. And for this you have to have historical data. So you actually say we should measure the cost of fixing bugs and so forth?
37:21
Yes, because you have to log the time somewhere, right? And you have to say okay, this is a simple fix. Why did it take so long to have it done? Why did it take so long to have it shipped? This translates to cost in terms of dollars immediately.
38:02
Our research paper here and there talking about how they perhaps tried to measure technical debt. And I'm really interested how come that we as a developer community and freelancers and a lot of us are living out of this, don't have like some tool that we could
38:22
just run on a code base and we could get things like hey, there is some technical debt in that file, that file, and that file. I mean you can already do that, but there are some other metrics and you have to be smart about it. How would you implement such a tool?
38:43
Yeah. So, good question. Yeah, exactly that. So the thing is really you can have indications for technical debt, but there's nothing that really tells you that there's no automatism that allows you to say there's technical debt in there.
39:01
Because especially given the sentence up there, translate to cost, right? There's no direct translation from something you find somehow in code to the cost it takes to fix it. The cost may actually be zero in some cases because you can sometimes say okay,
39:21
this is not done the right way, so it might cost us something to fix it, but not fixing it is actually okay, right? Because we are not seeing anything in the future that might force us into fixing it.
39:41
This is an example that is very good for instance in the banking industry. Some of the banking industry actually has mainframes that still run on COBOL. No one's gonna fix that code. They're gonna maintain it, they're gonna build interfacing around it, and they have people who maintain it.
40:00
It costs too much to have it fixed, for instance. Because sometimes you get a new situation when actually paying interest is the best option because fixing is more expensive. Yeah. Yeah, it was just a comment that sometimes you have situations when paying interest is the best business decision for you
40:23
because fixing it is too expensive and maybe the project is ending soon, then you won't be changing this code. You just pay the interest until the end. It's fine, it's cheaper. Yeah, and if you have technical debt that's isolated in a module, you have your interfaces well-defined.
40:40
It does the job, yeah. Yeah, I just want to add to the question about why don't we have a tool that can just tell you there's a technical debt of this time or this money. There actually are tools that can tell you that if you look, for example, at SonarQube, you can specify a cost of different code violations
41:06
and it will calculate it in dollars or time. It basically goes through your code, finds all the violations that you specify you want to look into, and just sums it up. It's actually a pretty good tool,
41:22
a pretty good tool if, for example, you have some legacy application and you are building a new feature, it's so huge you simply cannot eliminate the technical debt from the whole application. You just know that this one new feature, you will be working on it all the time,
41:41
so you want to eliminate as much technical debt from that code you are building right now, so it can actually tell you what's the difference from the rest of the application. There's a lot of stuff you can specify, but there are tools to do that. One thing that is in regards to tools,
42:03
they are going to measure your code quality. That's the first thing, that's the first step. You can automate and see, okay, I have these lines of code, I have undocumented code, I know this, I have so much responsibilities here,
42:21
I have this, this, and that. How do you measure technical debt when it occurs at an architectural level? Or at a specification level? So for basic stuff, yes, you can use tools.
42:41
It might or might not translate to cost. On the other hand, who's gonna fix the technical debt? Within a team, we are all developing on different levels. It takes more or less time, depending on who implements it, depending on the experience of the person who implements it. It's not something that is out of the box.
43:01
You have it out of the box, and everyone does it the same way. You, the plan to pay out the debt, you didn't exactly decide how do we pay technical debt to remove it, so refactoring or rewriting an application from scratch.
43:27
How can we measure when we should do one or the other, at which point? Actually, I did. What I mentioned there, but I didn't explain it, was all about communication and timelines and deadlines.
43:40
The decision, if you're gonna pay the technical debt and the interest incrementally, is a business decision. It's not a technical decision. Unless your code is completely unmaintainable and you're not able to write anything in that code, then the correct decision is to rewrite it. But even then, you're gonna have situations when the decision is going to be,
44:01
we're not gonna rewrite it, we're gonna rewrite it incrementally. It's not something that you can say as a rule when you're doing this and when you're doing that. When you decide to rewrite it, when you decide to fix it incrementally. Think about this. A software piece usually is maintained,
44:20
developed for five years, actually actively developed, and after five years, you get into maintenance mode. So that's technically the timeframe for a software piece, depending on the industry that you work in. You cannot just rewrite a piece of code that is one year old.
44:42
I mean, it's not necessarily the best decision. Unless you messed up at the specification level, and the specifications were completely wrong. But then you have the proof of value that should have validated this in terms of business. We got 10 minutes. I have a question. Is anyone here a fan of the Boy Scout rule?
45:03
I mean, that's one of the things I like to do when I get to a piece of ugly code, I need to work on it, I also fix whatever's ugly. I mean, personally I like to do touch as you go refactoring. I think if you get to the point where you need to go back
45:22
and refactor something after a long time, it's probably so costly that you won't do it, so maybe try to do a bit of refactoring every time you develop. Is anyone else a fan of that?
45:43
On the Boy Scout rule, I think it's important that you separate the code cleaner from the actual functional changes, that's all. But other than that, I mean, every time you see crap, pick it up, throw it away. There as well. At first, I was a little skeptic about this rule,
46:03
and I didn't believe that. But for example, our entire test suite for functional testing in web browser, at first was very messy and nobody wanted to touch that. But we started, this was our first internal project when we started using this rule.
46:23
And after about half year later, it was in much better design, it was slowly re-implemented, and every time we changed something, we tried to additionally fix a little the tests. There were other parts of our system
46:40
which were bad designed, and the rule worked also. So I can recommend it. And at first, don't be afraid of this. This will work in time. But it requires much more time than we can imagine at first, just to sit and rewrite it.
47:01
It will take much longer. Yep, true.
47:31
That's one way to put it. So it's about approaching legacy application. Application? You cannot get rid of that. It's about writing clean code
47:42
and make sure that you don't have, that you don't trigger old bugs. Well, my question is, how do you enter a new project? And this might also, excuse me, this might also be a solution for dealing with legacy applications. When you ramp up on a project
48:01
that's already being developed, one of the best ways to ramp up is to add unit tests, or add testing. When you have a legacy application, this also might be a good solution to see where your problems are. Because there are, I see two parts in what you described. One is writing your code that is clean and nice and neat,
48:21
and the other part is actually making sure that you do not have bugs, regressions, and so on. So you don't break anything that's already there. In order to be able to develop with a certain degree of certainty, you have to have at least the basic flows of an application tested.
48:41
Be it unit tests, be it integration tests, be it whatever, if it's a web application, I don't know, UI, Selenium tests. You have to have a certain degree of testing that will validate that what you built is the good solution. At least it doesn't break anything else. But this is one approach that I would take.
49:00
Work on the tests, add more tests, set up a continuous integration system, for instance, for that, if it's not already there. I think it's really important, too, that you have good code review,
49:21
that within a team, you agree upon certain standards, and yeah, people look at your code, give feedback, things like that. Absolutely, good code reviews are very important. Now, there are two types of code reviews. Don't try to code review something that can be automated.
49:41
Don't try to have, I don't know, PEP, staff pilot, and so on within code reviews. Use an automated tool for that. The problem with code reviews is that, well, you know, you have 30 lines of code. Whoever reviews it will say, will find probably 10 or 15 issues. You have a pull request for 500 lines of code.
50:02
The comment will be, looks good to me. So make sure that this is also enforced. Don't have large pull requests. Do it incrementally. Split things up in such way that will allow you to have smaller pull requests.
50:21
It's not always possible. When you, you know you submitted 500 lines of code, then it says, it looks good to me. Okay, review it again, please. I would like to make sure that this is actually okay. Because when you look at the code, you do a code review on the code base. Also, I think it's important
50:41
within the code review process to follow the requirements that led to that code change. Make sure that it also fits the business value or the part where the description, the requirement itself. And this brings up another discussion. When you have requirements, and probably if you're working agile,
51:01
you will have user stories. Make sure that you have, always have the three parts of a user story. As someone, I want to do something because that will allow you to have, at least to start a discussion about the best solution for the problem.
51:21
I wanted to stress out also in the team and communication part that sometimes, or maybe too often, we overlook the infrastructure level technical debt. And code people always tend to think that they have to deal with this type of database
51:43
because it's there in sense of just maybe trying to discuss with the ops guys and tell them maybe Postgres would fit better on my pattern and would allow me to avoid this kind of technical debt. That's absolutely, exactly, be the ops guys.
52:06
So very often, teams are split between the development team and operations team. Okay, there are two pains here. One is the operation team who has to deploy your code, and the development team who has to deal
52:21
with the constraints that come from the operations team. If you do not have the communication between these teams, if you have split teams, it's a very hard path. On the other hand, you as developers, I as a developer, should live with the pain of deploying what I wrote, right?
52:40
Everyone should live with that pain. Not only the ops guys. And on the other hand, possibly also the ops guys should live with some constraints of the application that we build. That's the only way to go. So be the ops guys. Try to be part of that ops team. See what they have to deal with.
53:01
Maybe it will allow you to better see why you have some constraints and some limitations within the project or within the teams. But indeed, Postgres is a better solution compared to MySQL at first.
53:25
Also how to avoid technical debt by using techniques like pair programming with your team, or like you said, reading small pull requests in your view.
53:42
How do you, what is your take? Pair programming versus small pull request? Yeah, I mean what are the techniques to avoid technical debt? It depends on how your organization is set up. If you can do pair programming,
54:00
do extreme programming, that's okay. Okay, yeah. So it depends on the context. It's not necessarily something that you enforce. Sorry? Yes, I think we still have a couple of minutes.
54:25
If I have, sorry. Any suggestions on that program? Pair people up who have different level of skills. That will be one thing that I would do.
54:44
Having an extra pair of eyes is always useful, but in this way you also grow your team. I think it makes sense to pair up a more junior programmer with a more senior developer. And it also might make sense to have
55:01
the more junior person typing, so the senior cannot step over the junior, like I'm just gonna type this up really quick, and the junior doesn't get what's being made. Absolutely, and one thing that was suggested to me in the team that I worked before was actually have junior people
55:20
review senior people's code, for instance. But that's different from pair programming. Both people involved in pair programming should follow the business rules. You have to make sure of that. Besides that, if you have automation for everything that's code-based related,
55:41
you should end up with the best solution from that construction. Sorry. So, you mentioned Boy Scout rule, and I had some great success, I think, with that, because I ended up basically with my first really big hobby Python project.
56:02
I ended up with 20,000 lines of codes, almost without tests. So, quite some technical depth. that running on different platforms and so it was kind of a pain. So I started to write tests
56:21
and then have a script with coverage.py where I have a list of perfect files, so files with 100% coverage, and for those files, the coverage may never decrease because it was too early to enforce coverage always increasing because there are
56:41
just some things which are not testable yet. So that's what I did and what worked out very well for me. Yep, that's one way to set it up. But on the other hand, don't rely on coverage would be my take because coverage also depends on how you write the test. Having 100% code coverage is not necessarily a goal.
57:04
It's having your business properly tested, that should be your goal. It might be 60%, it might be 80%. Some things might not be worth testing. At least that's my personal opinion. I know there are people who say, okay, we have to have full tests,
57:24
but it's not always possible. If you write an open source library and people rely on that, then yes, your coverage will be as high as possible because other people rely on your code. Within your project, it's also a business decision, or not necessarily a business decision, but an educated decision.
57:42
Have your main flows tested, have your positive, negative flows tested, but first of all, make sure that your code is actually testable. Input processing output. Single responsibility principle, and so on. Solid stuff.
58:02
A new project for making a new project easier to test, would it be smart or educated to adapt service-oriented architecture? If it fits your requirements,
58:22
and if it fits your project, sure. You can use a saw. Do you have architecture which are very difficult to test and which becomes a bad decision? Or not. Or not.
58:41
Well, again, the answer is it depends. Yeah, yeah. I've seen projects that are a monolith, and people wanted to split them up within microservices, and the reason behind it was that it would be easier to deploy. If you can't deploy a monolith, you will not be able to deploy and maintain microservices.
59:01
So it depends. Do we still have time? So officially, no. We're supposed to end about two minutes ago, but the coffee break starts in 15 minutes. I think we can, whoever wants to pop out, and the rest of us wanna just continue some questions and some discussion,
59:21
we can just gather at the front and just chat some more. Great. Thanks, guys. Oh, I had one more slide, actually. This is what happens when you try to fix that little bug in a fragile and rigid environment.
59:46
Thanks, guys.