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

[@EricKolotyluk]

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

[@Sande24]

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]

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]

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.

[@MMetalRain]

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

[@Tony-dp1rl]

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]

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]

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.