What is the actual life expectancy of your code?
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 | ||
| Number of Parts | 96 | |
| 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/51862 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201664 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
UMLComputer animation
01:17
Multiplication signProcess (computing)CodeVideoconferencingOrder (biology)Limit (category theory)Video gameWritingSemiconductor memoryComputer animation
02:56
CodeLine (geometry)NumberAverageAbstractionSoftware developerVideo gameArchaeological field surveyIntegrated development environmentCodeInformationReal numberStatisticsMultiplication signExpected valueSoftware developerSlide ruleWell-formed formulaRight angleBitIntegrated development environmentComputer programmingVideo gameData managementTwitterAbstractionProduct (business)ResultantLine (geometry)Total S.A.Projective planeNumberProcess (computing)Archaeological field surveyBuffer overflowStack (abstract data type)Point (geometry)Endliche ModelltheorieDivisorDependent and independent variables40 (number)AverageXMLComputer animation
08:23
CodeIntegrated development environmentInclusion mapExecution unitVideo gameCondition numberCodePhysical systemProduct (business)Software developerComputer programmingIntegrated development environmentTwitterVideo gameDifferent (Kate Ryan album)Category of beingGroup actionCondition numberFrequencyBitStatisticsControl flowWritingPoint (geometry)WordArmMereologyFocus (optics)Programmer (hardware)Computer clusterComputer animation
13:51
CodeRewritingPlastikkarteSoftware frameworkLibrary (computing)Execution unitSoftware testingCodeArchaeological field surveyPoint (geometry)Software frameworkMultiplication signAvatar (2009 film)Different (Kate Ryan album)Social classSoftware bugPhysical systemOnline helpCuboidCASE <Informatik>Projective planePattern languageAbstractionDivisorBuildingStatisticsService (economics)Software developerMereologyType theoryProcess (computing)Library (computing)Buffer overflowReduction of orderSoftware maintenanceOffice suiteStack (abstract data type)GoogolGroup actionFormal languageSingle-precision floating-point formatElectronic mailing listExecution unitSystem callParameter (computer programming)Right angleServer (computing)outputData managementComputer clusterTelecommunicationData storage deviceArithmetic meanBitModul <Datentyp>Line (geometry)Product (business)NumberSet (mathematics)Level (video gaming)WritingAxiom of choiceMultiplicationSurvival analysisSelectivity (electronic)Dependent and independent variablesFigurate numberBus (computing)Descriptive statisticsData structureVideo gameTerm (mathematics)Host Identity ProtocolSoftware testingDisk read-and-write headGame controllerInformation technology consultingData miningPerspective (visual)ResultantConnected spaceLimit (category theory)BlogNeuroinformatikSoftware repositoryRevision controlAbsolute value1 (number)Computer fileReading (process)Pulse (signal processing)Computer animation
Transcript: English(auto-generated)
01:35
remembers this show. Does it bring back any memories? Yeah, it does?
01:41
Cool. This is originally a French show called Once Upon a Time Man, but it aired in almost all of Europe. And whenever my mom took me to rent the video, because that's what you did back then, I would rent an episode of this. Now this show, Once Upon a Time Man,
02:00
it teaches kids about life. It teaches kids how life began, how life has evolved, and where we are headed next. Because as kids, this is our job. Our job as kids is to learn these small facts so that when we grow up and become adults, we can use these facts
02:21
in order to make the world a better place. And this is something we have to remember, using these facts in order to make the world better. Are we actually doing that every day? Is the code you're writing today, is that any better than the code you wrote yesterday?
02:43
Who knows? Is the life expectancy of the code you're writing today, is that any better than the life expectancy of the code you wrote yesterday? Because that's what we're going to talk about for the next hour. We're going to talk about what is the actual life expectancy of your code?
03:02
Is it increasing? Or is this simply something we tell ourselves to sleep better at night? Now, if you're here and you're expecting me to tell you the actual life expectancy of your code, then I'm going to start out by doing that. Here's the formula for calculating
03:21
the life expectancy of your code. You take the number of lines of code, and you divide that by the IQ of the developer minus the IQ of the project manager. You take the result and you do a modulus, the average number of coffee cups per day,
03:43
and then you add that to the total number of years of programming experience and divide it by the number of layers of abstraction. So let's try it out. So I have an example here. I have five million lines of code,
04:02
the IQ of the developer, 115, not impressive, but yeah. IQ of the project manager is, of course, a bit less. Three coffee cups per day, that might actually not be enough, but we'll try, and 16 years of programming experience
04:20
and three layers of abstraction. This gives us 6.33 years of life expectancy for this code base. So a bit over six years, that's okay, but it's not enough. So what do we have to do to increase this? Any ideas?
04:43
Drink more coffee? Let's try to increase the IQ of the developer. Increase it to 140. I mean, smarter people, we should be able to write better code, right? That didn't do much. We still get seven years.
05:00
So, nah, that didn't do it. Someone mentioned drink more coffee. What happens if we drink more coffee? Yeah, awesome. So this increases our life expectancy of the code to over nine years, that's great.
05:20
Now, of course, there is no formula for calculating the life expectancy. I'm sorry to disappoint you. I'm gonna tell you the conclusion of my talk right now. So if you don't wanna see the rest of it, you can leave after the next slide. I believe that the overall life expectancy
05:42
of code is decreasing. And I believe that it's our fault, the developers. This is something I've been thinking about for quite some time now. I'm not quite sure when it started or how I started thinking about this,
06:01
but it began after observing how developers are talking about their code, how they treat their code, how they're discussing code on Stack Overflow and Twitter and GitHub. And I just got this feeling that things are going to hell.
06:20
We're doing our jobs a lot worse than we should. Of course, I didn't have any data or any statistics to back this feeling up. So I might just be a crazy person, a really pessimistic crazy person. So what I did was I figured I had to find
06:41
some way of proving whether I was right or whether I was crazy. So what I did was I created a short developer survey. It had nine questions. And I posted it on Twitter.
07:00
I think it was open for about five days. And during those five days, I got 291 responses, which was a lot more than I'd expected. I'd expected maybe my colleagues to answer and then it wouldn't be useful because that would not show the general population of developers. But 291 responses, that's enough
07:23
to kind of play with these statistics and get something real out of it. So if you answered this survey, thank you very much. I would buy you a beer, but we're in Norway, so that's too expensive. So what kind of questions did I ask in this survey?
07:40
Well, I started out by kind of getting the background information of the people who were answering. So I started out by asking, somewhere out there, a piece of code I wrote 10 years ago is still in use in the production environment. Now, put your hand up if you have code in production
08:01
that you wrote 10 years ago or more. Okay, that's actually quite a lot. Cool. Well, here's what the surveys showed. 62.1% answered true. They have code in production that they wrote 10 years ago.
08:21
6.2 answered false. 11.4% don't know, because of course, you might not know if that piece of code that you wrote is still alive or if someone has rewritten it. And 20.3% did not write code 10 years ago. Okay, so that's looking backwards. What happens if we start looking forwards?
08:43
I believe the code I'm currently writing will still be used in a production environment 10 years from now. Raise your hand if you believe the code you're writing now will still be alive 10 years from now. Okay, so that's still quite a lot.
09:00
I'm impressed. Let's look at the answers. So for this one, 62.7% said true. 35.9% do not believe that the code I'm currently writing will be in production 10 years from now. And 1.4% are not writing code for poor people.
09:23
So this is, for the true part, it's roughly the same. Now, this is all good. I mean, this is statistics, but it doesn't really give us anything, right? This doesn't tell us anything. So what I wanna do is I wanna break this down
09:41
a bit further to see how these two questions relate to each other and see if that gives us any more insight. So what I've done here is I've divided the answers into two groups. You have the one group where the developers have 10-year-old code in production,
10:02
and then on the other side, we have the developers who don't have 10-year-old code in production. And I'm asking the same question. I believe the code I'm currently writing will still be used in the production environment 10 years from now. So as you can see, there's a difference now.
10:23
68.9% of the developers who have 10-year-old code in production believe that the code they're currently writing will still be in production 10 years from now, while only 53.2% of the developers who don't have 10-year-old code in production
10:40
believe that the code they're currently writing will survive 10 more years. So based on these statistics, we can conclude that having 10-year-old code in production actually increases the belief of the code that you're currently writing will survive.
11:02
Now, I'd like to talk about something completely different for a couple of minutes. I wanna talk about the life expectancy of human beings in Sweden. I'm sorry I didn't do Norway, but the Norwegian statistics are not as exciting. So this is what the life expectancy
11:21
of human beings looks like in Sweden. You can see it's been pretty good. There's a general increase ever since 1751. There have been four periods when being alive in Sweden was not very good. The life expectancy was quite short.
11:41
We had one in 1773. That was a famine due to failed crops. We had 1809, the Dano-Swedish War. 1857, there was a financial panic, and then, of course, World War I. But apart from those four low points,
12:01
the average life expectancy has increased steadily for over 200 years. Now, why is that? And this trend goes for most of Europe. So why is the life expectancy increasing? Well, it's because of our support systems, the support systems that we have around us.
12:22
For example, our living conditions have improved. We have proper housing. In Scandinavia, we have isolated houses. We have sanitation systems, which, of course, improve our hygiene. And we have access to clean water. Another support system is the public health offerings
12:43
that we have. We have medicines such as antibiotics. We have vaccination programs. We have a focus on nutrition. And in most of the Nordics, we have free healthcare, which, of course, helps a lot. And then, of course, we have education for everyone.
13:04
Why does education improve life expectancy? Well, because it prevents us from doing things like this. So our bodies haven't changed much in the past 200 years. I mean, we have two arms, we have two legs.
13:22
There hasn't, nothing drastic has happened to us as human beings. We are still the same. Yet, our life expectancy is increasing. And that is simply due to the support systems that we have around us. Our support systems have improved, and therefore, our life expectancy has improved.
13:44
So can we see the same thing for our code? When we write code, we have a lot of support systems as well. Those who believe that developers just write code, they're wrong. They're dead wrong.
14:00
Our jobs also consist of knowing how to use a lot of different tools and using them correctly. Now, this list is only a short list of the tools that we use every day. We have to be able to understand them, we have to be able to understand how we can benefit from using these tools.
14:23
So here we have, we have version control, we have testing, build servers, refactoring, deployment, documentation, performance monitoring, and the list goes on and on and on. So imagine for your next project, you were not allowed to use any of these tools.
14:42
And you can exclude Google and Stack Overflow as well. What would your code look like? Would your code be anything as good as the code you're writing now using these tools? No, I know mine wouldn't. So these tools are probably helping us, right?
15:06
Well, I had to ask about this in my survey as well to see if I got an answer for that. So I asked this. The tools I use daily in my development process, such as automated testing, build servers,
15:21
refactoring tools, et cetera, help increase the lifetime of my code. Raise your hand if you agree with this. Okay, so most people agree. 85.5% believe that the tools they are using
15:40
help increase the lifetime. But hold on. I'm standing here arguing that our support system is actually increasing the lifetime of our code and that the life expectancy in general is increasing.
16:01
But I started out this talk by saying that I believe that the life expectancy is decreasing. So where's the catch? I mean, something is not right here. Where's the catch? Who's the bad guy? Well, we're the bad guys.
16:23
Us, the developers, you and me. We are the bad guys in this picture. We have forgotten our responsibilities. Instead of viewing our code as science,
16:42
we've started looking at our code as a playground. Instead of fine-tuning existing code, instead of analyzing it, understanding how it works, we have developed a habit of throwing it away
17:01
and redoing it because we wanna create our own. We don't wanna work with something that someone else wrote. We wanna do it our way. So basically, our code is our playground. And of course, writing code should be fun.
17:21
That's the point of writing code. That's why we do it. But it shouldn't be this much fun. It should also be a bit painful. So another one of the questions in the survey was this. In the past six months, I have suggested to my team
17:40
or the product owner that we should rewrite an existing piece of code instead of spending time debugging and fixing it. Okay, 69.7% have done this.
18:01
They have suggested that they should rewrite the code instead of debugging and fixing it. Now of course, in this question, I'm only suggesting or I'm only asking who has suggested this. So what if we look at how many did actually rewrite the code?
18:21
Because of course, the product owner might have said no in this case, and they never actually rewrote it. So let's ask again. In the past six months, I have rewritten an existing piece of code instead of spending time debugging and fixing it.
18:41
In this case, 64.5%, so it's a bit less. So some of the people who suggested it obviously weren't allowed to rewrite it, and they had to spend time debugging and fixing it. But 64.5%, that's still a lot.
19:01
And I'm only asking in the past six months. What would have happened if I had asked within the past year or within the past two years? The number would probably increase. Of course, we have no idea why they're rewriting it
19:21
instead of debugging and fixing it. It could be that the code is so terrible that rewriting it is the only way. Or it might be that they're rewriting it simply because they felt like it. They didn't like what the code looked like. Or they wanted to use a different pattern than the code was originally using.
19:42
So to get a feeling of why the code was rewritten, I rephrased the question. And I asked, I have advised that a piece of code should be rewritten simply because rewriting it would be easier than having to figure out
20:01
how the original code worked. So I'm not saying we should rewrite it because it's making us more efficient. Or because it reduces costs. Or because the project manager wants us to. I'm saying simply because it's easier.
20:21
It's pure laziness. 60.7%, that's still a lot. Now, remember all those developers who believe that the code will be in production
20:45
10 years from now? Roughly the same statistics apply to them. So here we have a bunch of developers who believe that the code they're writing now will last for 10 years. But at the same time, they are advising
21:02
that code should be rewritten simply because it's easier. Isn't expecting your code to live long while being quick to rewrite code, isn't that somewhat contradictory? How do you expect your code to live for a long time
21:20
if you keep rewriting everyone else's code? So most of us are quick to rewrite code rather than fix it. Is that always worth it?
21:44
Being able to maintain someone else's idea alongside your own is what separates a great developer from an average one. This was made as a comment on my blog a while back and I haven't been able to identify the person who wrote this,
22:01
but I absolutely love what he or she is saying here. We have to realize that there is value in understanding what already exists before we start making calls about its limitations. We know that legacy code has value
22:22
and of course, rewriting it has a cost. The time you spend, that costs money because you cannot develop new things. So from a productivity perspective, is it always worth solving the same problem twice?
22:44
My guess is probably not. But sometimes it is and sometimes it isn't. Now, one of the things that usually leads to unnecessary rewriting of code is our fascination with shiny new toys.
23:03
All developers love shiny new toys, right? We are so easily mesmerized by new shiny frameworks, new shiny languages, new shiny libraries that we just wanna rewrite our code using all of these new shiny things.
23:23
There's a developer called Daniel Bay, a Swedish developer. I don't think he's here. He tweeted this a while back. Everything seems stable in production and we've seen a decline in bug repo. Oh, look, new shiny.
23:41
Has anyone experienced this before? Yeah, you're finally happy with the result. Everything is stabilizing, starting to work and then there's just this awesome new framework that you have to try out. I have a friend of mine and it's always a friend, you know,
24:01
a consultant who was working with a customer. When you first started working with them, all their front-end code was HTML, CSS and I think they were using jQuery. Then after a while, Knockout.js came along and they thought, wow, this is really cool. It's so powerful. We should just rewrite all of our front-end code
24:23
using Knockout.js and so they did and of course, it took some time. Then not long after, AngularJS came along and they thought, wow, this solves all our problems that we have in Knockout.js.
24:41
Maybe we should just rewrite it again. Of course, we know that it's gonna take some time. We know that it's not gonna enable us to write all the new features that we want right now but in the long run, we're gonna benefit from doing this, right? This is not a very efficient way of working yet this is what we do every single time as developers.
25:04
We keep rewriting things because new shiny frameworks, languages and libraries show up. So of course, I had to ask about this in my survey as well. I had to ask, I have replaced a third party
25:24
library or framework with another simply because I wanted to try out the new library or framework. This is purely selfish. You're rewriting it because you want to try it out.
25:42
It's not for the benefit of the project you're working on. It's not to reduce cost. It's not to get the newest best features. It's because you personally want to try it out. 35.5% of the developers said yes.
26:03
And these statistics, these scare me a lot and I'm part of these statistics. I did the survey myself and I'm one of them. Yeah, I'm one of these and this is terrible. Over a third of all developers are doing things in their projects that the project might not benefit from.
26:24
It's purely selfish reasons. Now of course, introducing new shiny things in your projects, it involves risk. You have the risk of bugs. Whenever you try something new, you're always able to get that one bug that no one else has and it takes a bunch of time
26:43
trying to figure it out. There might be a lack of developer support if you're one of the really early ones. And of course, there's a lack of knowledge within the project team. Although you think it's all right
27:01
to try out new shiny frameworks, what about your colleagues? Do they spend every night looking at the same frameworks? If they don't and you're the only one on your project who has this knowledge, you're increasing the bus factor. And you all know what the bus factor is, right? You get hit by a bus, what happens?
27:22
And of course, there's a chance that this new shiny framework will be discontinued or completely changed. We've seen that happen, right? So introducing new shiny things involves risk. And this is why introducing such things
27:41
has to be done on a strategic level. It shouldn't be done because one developer on the project wants to try it out. If that is so, you should try it out on your own time, not during office hours. So again, we have forgotten the science involved
28:02
in writing code. And instead, we view our code as a playground. We introduce new frameworks and new libraries without calling the risk. And essentially what we're doing is we're calling time of death on our own code.
28:26
In the ER, doctors make sure that they've tried everything, all types of resuscitation before they can call time of death on a patient.
28:41
Absolutely everything they can, they do. We call death all the time on our code, daily almost. And we do it for various reasons. I mean, we can look at a piece of code and we can say, nah, it's not pretty enough.
29:00
I hope doctors don't do that, that would be terrible. Or you can look at the piece of code and you can think, well, you know what? I can write this better. I can make this more loosely coupled. Or maybe it needs more abstractions or less abstractions.
29:20
Or you might not agree with the pattern that's being used. Or, and this is my favorite, you might look at that piece of code and you might say, you know what? It's just not readable. And I wanna talk about this for a second
29:42
because there's a difference between unreadable code and unreadable code. Now, unreadable code is code that is not clear enough to be read or interpreted. So in this case, the code is the problem.
30:03
And then you have unreadable code, which means that the reader does not possess the required knowledge to read the code. You see the difference here? One's the code, one's the reader. Just because you're not able to read Shakespeare
30:22
does not mean that you should throw away all his works and try to rewrite it on your own. So looking at our code, when is it appropriate to start calling time of death?
30:43
For medics in the ER, it's quite easy to know when they call time of death. I mean, the patient has no pulse. You got the answer. But for us, how do we know when it's time to delete a piece of code or to completely rewrite it? When is the correct time?
31:02
Is it when the code is unreachable? Is it when the code is dead, when it's deprecated, or when it's legacy? I wanna go through all of these. And let's start with unreachable.
31:21
So what is unreachable code, first of all? Unreachable code is code that exists in the code base, but it's never executed. So you might have a method, and that method is never called, or a class that's never used, or it might be code that's commented out.
31:41
So you have lots of code that's never used. I mean, that's completely useless. So of course, you can call time of death on unreachable code. Dead code. Dead code is code that is executed, but the result of that execution is never done
32:03
or is never used in any other computations. So here you're just doing lots and lots of work for nothing. So of course, yeah, you should probably call time of death on dead code as well. Deprecated code, we should all know this.
32:23
Deprecated code is code that is superseded or obsolete. And of course, that should be avoided if you can. So this code, it only exists for backwards compatibility. So at some point, you should call time of death
32:40
on deprecated code, but you might want it to exist for some time. So call it when appropriate, when you reach that time when it's no longer needed. Now, what about legacy code? Legacy code is a difficult one
33:00
because no one is able to agree what legacy code is. So legacy code, well, that kind of depends on your definition. So what's your definition?
33:21
If you tell a colleague that this piece of code is legacy code, they're gonna understand you loud and clear. They're gonna understand what you're saying. But if you ask someone to define legacy code, to give you a precise definition of what legacy code is,
33:41
you could get anything in return. Those of you who have read this book, Working Effectively with Legacy Code by Michael Feathers, you're probably gonna argue that legacy code is code that has no unit tests, right? Who's read this book?
34:01
It's a great book. But I actually prefer his other definition of legacy code, which is in the same book, and it's this. Now, I'm gonna let you read this for yourself before I start reading it.
34:33
Legacy code is code from the past, maintained because it works.
34:40
But for people who deal with it, day in and day out, legacy code is a Pandora's box. Sleepless nights and anxious days, pouring through bad structure, code that works in some incomprehensible way, days adding features with no way of estimating how long it will take.
35:03
Who recognizes this feeling? I think it's a perfect description of what it's like to work with legacy code. But it still doesn't give us a definition of what legacy code is, because what I want,
35:21
I want an absolute definition, so that if I were to ask a thousand different developers, is this piece of code legacy, they would all give me the same answer. As of now, that's not gonna happen, because all those thousand developers will have, some of them might have the same definitions,
35:40
but there will be several different definitions going around. So of course, I had to ask about this in my survey as well. In your opinion, what makes code legacy?
36:02
For this question, all the respondents were allowed to select multiple choices. That's why the numbers don't add up to 291. 13 people, or 13 developers, believe that it's legacy if someone other than I wrote it.
36:21
Okay, so apparently, these people are the only people in the world who don't write legacy code. That's cool. 57 percent, no, 57 people, or developers, believe that it's legacy as soon as it's in production.
36:41
102 developers believe it's legacy if everyone who wrote it are no longer on the project. 115 people believe that it's legacy if it lacks unit tests, so they obviously read Michael Feather's book. And then 180 people believe it's legacy
37:01
if it's written in an old language or uses old libraries or frameworks. 77 people believe all code is legacy after X number of years. Now, you can see here that 63 said other. And whenever you selected other,
37:23
you had to specify your own definition. So you had to type in the definition of legacy on your own. So what did these people define legacy to be? Here's one.
37:43
It's legacy if you're scared to touch it for whatever reason. And there were an amazing amount of answers similar to this where developers are afraid, they're scared, they're nervous and I had no idea that our jobs were this terrifying.
38:04
Now, of course, if I look at a piece of code, I might think that that piece of code is really scary. But then my colleague might look at the same code and might say, well, there's no problem with this. This is easy. So this is not an absolute answer.
38:23
This still depends on who you ask. So it's not an absolute definition. So let's try another one. It's legacy if the code is there but the meaning is not.
38:41
And this is a deep one. You can start thinking about this and you can kind of get stuck in your head and just, wow. Because what's the meaning of code? I mean, we all know that the meaning of life is code but what is the meaning of code? That also kind of depends on the eye of the beholder.
39:04
So while I really like this one, it's not an absolute definition. So here's another one.
39:22
Every time I open a file and it's not empty, it's legacy. I kind of feel sorry for the person who wrote this. Every time you write a piece of code and you hit save, it's legacy. So easy as that. So if this was our definition of legacy code,
39:43
we wouldn't actually need the term legacy because all code would be legacy. So I'm not gonna accept this one either. It's legacy when there is no reasonable upgrade path to a modern system.
40:02
And I think most people would agree with this definition. This is quite good. But there's a catch. This definition requires all legacy code to be written in a non-modern system.
40:21
But we've all seen code written with the newest frameworks, fanciest languages, that's the legacy. So in this case, with this definition, we're saying that it's not possible to write legacy code in modern systems. So of course it is.
40:41
We do that all the time. So how would I define legacy code then? If I'm not happy with any of these definitions, how would I define it? Well, I would say that code becomes legacy when continuing maintenance becomes more expensive
41:00
than rebuilding or rewriting it. Of course, you can argue this as well. There are lots of arguments against. I mean, more expensive, what's that? Are we talking money, time? Are we talking maintenance?
41:20
I don't know. And when do you reach the tipping point of more expensive? Is it because it's badly written? Is it because the technology is outdated? There are so many factors to consider here that finding an absolute definition of legacy
41:41
is quite difficult. So going back to this, when is it appropriate to call time of death on legacy code? Well, it depends on your definition. And one day I hope that we're all able to agree
42:00
on one definition of legacy. But I'm afraid that's gonna be quite difficult. So the really interesting question then is, does a developer's definition of legacy, does that impact if and when you decide to throw away your code and rewrite it
42:22
instead of debugging and fixing it? So based on the statistics that we've already seen, I wanna break this down and show it to you in a different way to see if we can answer that question. Does the definition of legacy impact your willingness to rewrite code?
42:43
So here we see that out of all the developers who believe that code is legacy if it lacks unit tests, 62% of them have advised that a piece of code should be rewritten simply because rewriting it would be easier
43:00
than having to figure out how the original code worked. So 62%. Now, what about those who think that it's legacy as soon as it's in production? Is there a difference there? Yes, there is. Out of the developers who believe that it's legacy
43:21
as soon as it's in production, 73% have advised that a piece of code should be rewritten simply because it's easier. So already we see that there's a difference. What about the developers who believe that legacy code
43:40
is any code that someone else has written? Well, 92% of them have advised that a piece of code should be rewritten simply because rewriting it would be easier than having to figure out how the original code worked. So looking at these numbers, it seems like your definition of legacy,
44:05
it actually impacts the life expectancy of your code. That has an impact on how quick you are to rewrite your code, or someone else's code for that matter, instead of analyzing it, instead of trying to understand how that code is working.
44:26
So let's try to sum up the facts and see what we've got so far, because we have a lot of numbers and we have a lot of statistics and we want to see how this all adds up. So we know that the support systems around us
44:43
and the technology that we use, it helps increase the life expectancy. And we know that having old code, having 10-year-old code in production, that increases your belief in code surviving.
45:04
We know that most of us are quick to rewrite rather than fix code, which of course decreases life expectancy. We know that we view code as our playground, introducing risk, which decreases life expectancy.
45:23
And we know that your definition of legacy code impacts the life expectancy of the code that you're writing. Based on all of this, I believe that the overall life expectancy of our code is decreasing.
45:42
So how do we change this? Because we want the code that we write, we want it to be able to last without someone else rewriting it simply because they can understand it, or simply because they didn't agree with the pattern you used. So how do we turn this around?
46:03
Well, we have to start out by building a strong foundation. There is no point in building a house if the ground it's built on is weak. That's not gonna last long, right? And the same goes for our code.
46:21
We have to make sure that the foundation that we write our code on is strong enough. We have to focus even more on writing clean code, modular code, and maintainable code. And you might think, oh, this clean code thing again?
46:42
That's all people are nagging about. But honestly, we're not nagging enough because we're still rewriting each other's code without even trying to understand it. So we need to focus even more on this.
47:04
We have to view code as our means of communication because code is how developers communicate. Yes, we have comments to our code, we have documentation that come with our code, we have commit comments, and all of these are also a way of communicating.
47:24
But the code itself, that is how we communicate with each other. The code is where the intent is shown. The code is where you should realize what the writer of the code was thinking.
47:43
But communication always fails at some point, right? So we also have to improve our ability to deal with other people's failure to write clean code. We have to be better at reading code. It doesn't help if you get better at writing code
48:02
and then you're not able to read someone else's code. You have to be able to read other code as well. So the next time you're tempted to rewrite a piece of code, don't rewrite it simply because it's easier than trying to understand. You should assume that the developer
48:21
who wrote the piece of code has a brain. And you should assume that the developer is able to use that brain. So view it as a learning experience. What is the previous developer trying to tell you with this piece of code?
48:40
What are they trying to communicate? I've made all the statistics for this survey public, so if you'd like to dig in, see if there are some connections that I haven't seen, all the results are there and you can analyze it yourself.
49:04
I'm cutting it a bit short today because if you might have noticed, I have a cold. I'd like to say thank you for attending and if you have any questions at all, please contact me. Thank you.