Code Red: The Business Impact of Code Quality • Adam Tornhill • YOW! 2022

Подписаться 997 тыс.

Просмотров 4,7 тыс.

50% 1

This presentation was recorded at YOW! 2022. #GOTOcon #YOW
yowcon.com
Adam Tornhill - Founder & CTO at CodeScene, Programmer, Psychologist, Lisp Hacker, Speaker & Author ‪@adamtornhill2546‬
RESOURCES
arxiv.org/abs/2203.04374
codescene.com/hubfs/web_docs/...
Adam
/ adamtornhill
github.com/adamtornhill
/ adam-tornhill-71759b48
www.adamtornhill.com
ABSTRACT
Code quality is an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for new features. The resulting technical debt is estimated to waste up to 42% of developers' time, causing stress and uncertainty, as well as making our job less enjoyable than it should be. Without clear and quantifiable benefits, it's hard to build a business case for code quality.
In this talk, Adam takes on the challenge by tuning the code analysis microscope towards a business outcome. We do that by combining novel code quality metrics with analyses of how the engineering organization works with the code. We then take those metrics a step further by connecting them to values like time-to-market, customer satisfaction, and road-map risks. This makes it possible to a) prioritize the parts of your system that benefit the most from improvements, b) communicate quality trade-offs in terms of actual costs, and c) identify high-risk parts of the application so that we can focus our efforts on the areas that need them the most. All recommendations are supported by data and brand new real-world research. This is a perspective on software development that will change how you view code. Promise. [...]
TIMECODES
00:00 Intro
00:28 What is technical debt?
05:29 Visualize technical debt & code complexity
14:39 Quantify the business impact of code quality
18:20 Does code quality matter?
27:01 Prioritize remediation to large amounts of red code
37:29 Resources
37:55 Outro
Download slides and read the full abstract here:
yowlondon.com/2022/sessions/2247
RECOMMENDED BOOKS
Adam Tornhill • Your Code as a Crime Scene, 2nd Ed. • amzn.to/44khqgE
Adam Tornhill • Software Design X-Rays • amzn.to/3DEeEnI
Adam Tornhill • Your Code as a Crime Scene • amzn.to/3FI5E2V
Adam Tornhill • Lisp for the Web • leanpub.com/lispweb
Adam Tornhill • Patterns in C • leanpub.com/patternsinc
Caitlin Sadowski & Thomas Zimmermann • Rethinking Productivity in Software Engineering • amzn.to/41ztwjs
/ gotocon
/ goto-
/ gotoconferences
#CodeScene #CodeAsACrimeScene #AdamTornhill #TechnicalDebt #Legacy #LegacyCode #DeveloperProductivity #CodeComplexity #Complexity #CodeSmells #RedCode #GreenCode #CodeQuality #CodeHealth
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ru-vid.com...

Наука

Опубликовано:

27 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 8

@EricKolotyluk 10 месяцев назад

Very interesting... Hope to play with CodeScene soon...

@MMetalRain 10 месяцев назад

Can you have important code that is green? Or does core parts of your program always have more changes and errors?

@Sande24 10 месяцев назад

The assumption that a large file is somehow more dangerous than a bunch of smaller files is kind of flawed. You can have a logical flow in one file but if you split it up, it might become harder to maintain a bunch of files that do not make sense individually but are a part of a bigger picture. A larger file has an effect of less coupling and higher cohesion. With a bunch of smaller files, you could cause higher coupling in the long run as the meaning of those small files tend to become bloated and the responsibilities become shared between other functionalities. Or you'd have to create some other overhead of preventing that from happening. These red-green bubbles have been created based on subjective metrics. It most likely does not see the bigger picture, so it just paints smaller files as green as it has less chances to have nested loops or long functions etc. The idea about using git history to judge whether something actually needs to be changed is interesting. tl:dr; Fixing code is more subjective than this talk makes it seem.

@D4no00 10 месяцев назад

I was going to watch this talk, however you comment makes it clear enough to understand that the entire talk is just bragging on subjective matters, developers like to brag on how smart they think they are. With regards to files I agree with you, there is no silver bullet to this problem and it varies from project to project and team to team. The most important metric that should be taken into consideration is code clarity, both for people working a long time in the project and for new people and if you fail to do that, then everything else just has such a small value that can be ignored.

@pwhqngl0evzeg7z37 10 месяцев назад

You're comparing long files done well, versus small files done poorly. Of course, a poor analysis of a problem, combined with using small files, will result in the issues you describe, but a good analysis is better than no analysis, as would be the case in a long file. But, you may say, you could have a large file that manifests a good analysis. But then you can split that file into smaller ones without tight coupling. If not, then the analysis cannot be good. A good analysis enables complete understanding of subparts. Of course, there may be problems which do not permit much analysis, but I am an optimist.

@Tony-dp1rl 10 месяцев назад

There is something very counter-intuitive and somewhat ironic in this talk. CoreCLR is an extremely successful code base and has been for many years. Doesn't that counter your arguments a little? CoreCLR will still be around long after React is dead I imagine, regardless of code quality. Perhaps there is more to it than a metric of code quality per module. I am guessing it is because not all code is important to the overall product, or changing often. The quality metric of the code that is changing the most is probably a lot more useful metric - that is where bugs get introduced. Nobody cares if the old code is badly written if it is performing well and never needs changing.

@JohnDoe-bu3qp 10 месяцев назад

That's exactly what the talk is about. 1- What he is talking about; 2- Why should a business person care; 3- How can you tell whether code is good or bad; 4- Is all bad code as impactful? 5- What to do about impactful bad code; 6- Where to find out more.

@FlamencoDeniz 10 месяцев назад

sounds like the naive assumption that success = good quality, which is generally not true. if you have the shittiest house in a high demand region you can still sell it at a "successful" price. other examples can be found in music, cars, heck probably any product. economic success does not infer a good quality. it is more an indicator of a positive margin than quality of product.