What is the actual life expectancy of your code?
•Download as PPTX, PDF•
2 likes•1,828 views
As developers, our toolset for maintaining and improving our code spans from automated testing to build servers, refactoring tools, automated deployments etc. All these support systems are meant to improve the life expectancy of your code. At the same time, new programming languages and frameworks are being launched every month and choosing the wrong one might have fatal consequences for your codebase. So let's ask ourselves: Is the life expectancy of our code actually improving? Or is this just something we like to tell ourselves to sleep better at night? And when is it appropriate to call time of death on our code?
Recommended
Recommended
More Related Content
Similar to What is the actual life expectancy of your code?
Similar to What is the actual life expectancy of your code? (20)
Recently uploaded
Recently uploaded (20)
What is the actual life expectancy of your code?
- 2. 𝐿 𝐼𝑄 𝐷𝑒𝑣 − 𝐼𝑄 𝑃𝑀 % 𝐴𝑣𝑔 𝐶 + 𝑌𝐸 𝐿 𝐴 where L = Number of lines of code 𝐴𝑣𝑔 𝐶 = Average number of coffee cups per day 𝑌𝐸 = Years of programming experience 𝐿 𝐴 = Number of layers of abstraction
- 3. Lines of code: 5,000,000 IQ of developer: 115 IQ of project manager: 110 Average number of coffee cups per day: 3 Years of programming experience: 16 Number of layers of abstraction: 3 Life expectancy: 6,33 years
- 4. (And it’s our fault)
- 5. 9 questions 291 respondents
- 6. True 62.1 % False 6.2 % I don't know 11.4 % I didn't write code 10 years ago 20.3 %
- 7. True 62.7 % False 35.9 % I'm not currently writing any code 1.4 %
- 8. 68.90% 53.20% 28.9 % 46.8 % 2.2 % 0.0 % 0% 10% 20% 30% 40% 50% 60% 70% 80% Devs with 10 years old code in production Devs without 10 year old code in production True False I'm not currently writing any code
- 15. Version Control Testing Build servers Refactoring Deployment Documentation generators Performance Monitoring And the list goes on and on...
- 17. We are...
- 22. ...is what separates a great developer from an average one
- 23. - @bergdaniel
- 27. Unreadable code The code is not clear enough to be read or interpreted «Unreadable» code The reader does not possess the required knowlegde to read the code.
- 28. Unreachable? When code is... Dead? Deprecated? Legacy?
- 29. Unreachable? Call it! When code is... Dead? Deprecated? Legacy?
- 30. Unreachable? Call it! When code is... Dead? Call it! Deprecated? Legacy?
- 31. Unreachable? Call it! When code is... Dead? Call it! Deprecated? Call it when appropriate. Legacy?
- 32. Unreachable? Call it! When code is... Dead? Call it! Deprecated? Call it when appropriate. Legacy? Depends on your definition.
- 34. - Michael C. Feathers
- 35. 13 57 102 115 180 77 63 0 20 40 60 80 100 120 140 160 180 200 It's legacy if someone other than I wrote it It's legacy as soon as it's in production It's legacy if everyone who wrote it are no longer on the project It's legacy if it lacks unit tests It's legacy if it's written in an old language, or uses old libraries and frameworks All code is legacy after X number of years Other
- 40. How I would define it
- 41. Unreachable? Call it! When code is... Dead? Call it! Deprecated? Call it when appropriate. Legacy? Depends on your definition.
- 42. It’s legacy if it lacks unit tests 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. 62%
- 43. It’s legacy if it lacks unit tests It’s legacy as soon as it's in production 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. 62% 73%
- 44. It’s legacy if it lacks unit tests It’s legacy as soon as it's in production It’s legacy if someone other than I wrote it 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. 62% 73% 92%
- 46. Support systems and technology increase life expectancy Most of us are quick to rewrite rather than fix code, which decreases life expectancy We view code as our playground, introducing risk, which decreases life expectancy
- 47. So how do we change this?
Editor's Notes
- That's what we'll do for the next hour, we'll investigate whether the life expectancy of our code is actually increasing or whether we just tell ourselves that to sleep at night.
- Change developer IQ to 140: Life expectancy increases to 7 years Change number of coffee cups per day to 6: LE increases to over 9 years
- For everyone else: I believe the overall life expectancy of code is decreasing and it's our fault This is something I’ve thought about for quite a while, after seeing how code is treated and how developers behave. Problem was, I had no statistics to back up this statement.
- Raise your hand Stats
- Raise your hand Stats Now, I want to break this down a bit further to see how these two questions relate to each other
- Stats
- Based on these answers... Now, I’d like to talk about something completely different for a couple of minutes: The life expectancy of human beings in Sweden
- 1773: Famine due to failed crops 1809: Dano-Swedish war 1857: Financial panic 1918: World War I Other than that, the life expectancy of humans has increased steadily for 200 years. Why?
- Housing Sanitation Access to clean water
- Medicine such as Antibiotics and Vaccination programs Nutrition Free health care
- Free for all
- So our bodies haven't changed much in these 200 years, we are stil the same. The support systems have simply improved. Can we see the same trend for our code?
- Those who believe developers just write code are wrong, our jobs also consist of being able to use our toolset correctly. This is only the beginning of a long list of tools we need to understand and be able to use. Imagine for your next project, not using any of these tools. What would that do to the life expectancy of the code you’d write?
- Stats But hold on, I'm standing here arguing that our support systems increase the life expectancy of code. Yet in my introduction, I said that the overall life expectancy of code is decreasing. Where's the catch?
- Who's the bad guy? We are the bad guys. Us, the developers. We have forgotten our responsibilities.
- We've forgotten the science involved in writing code and instead we view code as our playground. Instead of fine-tuning existing code, analyzing, understanding, we have developed a habit of throwing it away and redoing it. We create our own.
- Stats Remember all the devs who believe their code will be in production 10 years from now? Roughly the same stats apply to them. Isn't expecting your code to live long while being quick to rewrite legacy code somewhat contradictory? Doesn't it increase the chances of someone else rewriting your code before it reaches its 10 year anniversary? Most of us are quick to rewrite rather than fix code, is it always worth it?
- We have to realize that there is value in understanding what already exists before making calls about its limitations. One of the things that leads to potentially unnecessary rewriting of code is our fascination with new toys. We're easily mesmerized by new, shiny frameworks, languages and coding styles. This makes us want to rewrite our code, using these new tools.
- Developer ADHD Example: Friend (always a friend, huh?) worked with a customer. Frontend was all HTML/CSS and Jquery. Knockout came along, they rewrote their frontend code. AngularJS came along, another rewrite. Not a very efficient way of working
- New, shiny things involve risk: Bugs Lack of developer support Lack of knowledge within the project team Chance of it being discontinued or completely changed in the future? (Angular) The decision of accepting these risks has to be done on a strategic level.
- Again, we've forgotten the science involved in writing code, and instead we view code as our playground. We introduce new frameworks/libraries without considering all the risk, essentially calling time of death on our code.
- In the ER, calling time of death is only done after repeated attempts at resuscitation, when they're sure there is absolutely nothing else they can do for their patient. Developers call time of death (and consequently rewrite or remove) for various reasons: Not pretty enough I can write this better/more losely coupled It needs more abstractions... it needs less abstractions I don’ agree with the pattern used It's not readable
- It's quite easy for medics to know when they can call time of death, when the patient no longer has a pulse. Unreachable code: Code that exists, but is never executed. Completely useless, call it!
- Dead code: Code that is executed, but whose result is never used in any other computations. In other words, useless. Call it!
- Deprecated code: Code that is superseded or obsolete, and therefore should be avoided. The code exists only for backwards compatibility. Call it when appropriate.
- Legacy code: Difficult one, because no one agrees on what legacy code is.
- If you tell someone «this code is legacy», they will understand what you’re saying. Your message is received loud and clear. But if you ask the same person to define what legacy is, you might get anything in return. Those who have read ... By Michael Feathers are likely to argue that legacy code is code that lacks tests.
- Describes the feeling of working with legacy code, but doesn’t give a definition I want an absolute definition, that always gives you the same answer regardless of who you ask. If I were to show a piece of code to 100 people and ask them, they would always give the same answer.
- Stats What about the «other» option?
- Many mentioned being scared, nervous or frightened. I might be scared, while my colleague is not. Depends who you ask, therefore not absolute definition.
- What is the meaning of code? This also depends on the eye of the beholder.
- All code is legacy. If all code is legacy, there is no point in even using the word legacy, we can just say code.
- This definition requires all legacy code to be written in a non-modern system. But we’ve all seen legacy code in modern systems, haven’t we?
- "For me, code becomes legacy when continuing maintenance becomes more expensive than rebuilding/rewriting it. Whether this ‘tipping point’ is reached because of badly written code or outdated technology doesn't matter, these are all factors that contribute to code becoming legacy."
- Back to this, when is it appropriate to call time of death on legacy code? It depends on your definition. The really interesting question then: Does a developers definition of legacy impact if and when you decide to throw away and rewrite a piece of code instead of debugging and fixing it?
- 62% of those who agreed with the statement it’s legacy...
- 73% of those who agreed with the statement it’s legacy...
- 92% of those who agreed with the statement it’s legacy...
- Your definition of legacy impacts if and when you decide to throw away and rewrite a piece of code instead of debugging and fixing it.
- Support systems and technology increase life expectancy Having old code increases belief of code surviving. Most of us are quick to rewrite rather than fix code, which decreases life expectancy We view code as our playground, introducing risk, which decreases life expectancy Your definition of “legacy” impacts the life expectancy of code
- No point in building a house on weak foundation. Won’t last long. Same goes for code. We have to focus even more on writing clean, modular, maintainable code.
- Code is how we communicate Not just to computer, but to other developers Communication will fail, and therefore we also have to...
- Don’t rewrite simply because it’s easier than trying to understand. Assume that the developer who wrote it has a brain and was able to use it. View it as a learning experience: What is the previous developer trying to tell you?