Thank you very much, erikig, this is much appreciated! ⭐️

It's legacy code when it's written and even more so the day after.

Keeping code as clean as possible all the time is a neat ideal, but we can't achieve it in practice. In his talk he mentioned 4.000 years of technical debt accumulated in 15 years. He named parallelization of multiple developers as a possible way for that particular scenario to occur, but I don't think it's too farfetched to think that 1 developer, 1 hour of developing can accumulate multiple hours of technical debt. Of course it depends on what we characterize as technical debt but what I'm getting at is that technical debt diverges. The more efficiently we develop the more technical debt we will accumulate - as the efficiency will be derived from the shortcuts that we take and they will all accumulate technical debt. That technical debt will likely hamstring us in the future. I believe the most productive way to develop is to take the technical shortcuts that provide the "best" trade-off between efficient development and technical debt accumulation. So achieving 0 technical debt although an ideal would never be feasible. What we can instead more realistically aim for is to set aside a portion of our development capacity to solve just enough of the technical debt that we produce in order to maintain a constant development speed. If we managed to do that we would have achieved what I believe to be perfection. In practice though we will of course all fall short of that goal and experience varying degrees of slowdown.

I think it's not possible. Mainly because when you write a new feature, you really don't know what it is and how to model and design it correctly - this understanding only comes after you have coded it. I think there is no point to try to write perfect code from beginning, but to write what you can, then release, then refactor.

You make a salient point. Hotspots at any point in time can be influenced by the demands of the software at the time they were measured. If those demands change, entirely new hotspots could all of a sudden light up. For example, an unexpected regulatory change could force you to refactor code that was supposed to be extremely mature. But even still, those are scenarios that you can't predict. I would say you're still better off going after the technical debt that has more probability of hurting you, and that is the stuff that is accessed most frequently.

It would make me question the files cohesivenesses though. Maybe it should be different files? Just something to consider, not a hard rule.

Exactly this. I don't think that anybody would consider lower importance tech debt eg bank software written in fortran, cobol or even perl that nobody understands and that you can't even easily find skilled (or willful) developers to work on in case of need. That is just a time bomb ready to explode, you just don't pay the cost of it every day, but all at once after 15 or 20 years. Also the talk focuses too much on "code" and "code changes" (commits). Certain tech debt is due to horrible, not scalable and entangled architectures. There the complexity is not measurable at all via any kind of code analysis tools

If you must change some code for your feature, it doesn't really say anything about the complexity because that's simply what you have to do to make it work. We could only reasonably say the complexity is low if we would have a time metric included as well which is very difficult to do and on top of that every developer is different so maybe even that would not be a solid proof.

Agree, obv the metrics discussed are useful/insightful, but could perhaps be more accurate regarding actual risk/impacts. Great place to start though and very interesting to see the examples!! Great talk, thanks

Also, lol at assessing risk based on whether or not the developer is going to leave. People jump ship without warning, especially in environments where those developers are in the high pressure position of being strongly relied upon.

A 500 line function is a problem. Even if you refactor this into helper functions that aren't used anywhere else, it's easier to unit test the helpers and keep the main function easier to read.

@@TheBswan It might be technically possible to have some code that can't be refactored into helper functions because the code itself is doing one peice of work, but it would seem pretty unlikely. And, if you could refactor them into helper functions, you should. Especially if those functions can be given specific names outlining exactly what they are doing and why, that way the main function is basically just explaining how the main function works. -- I have seen this many time where people put a bunch comment explaining the next stage of this function. And the best refactor was just moving each of those sections into functions and naming the function what that original comment said.

The whole measuring somebody purely on code contribution is a problem. I do recall one time I spent five hours on a piece of code to remove one letter 'e'. I'm pretty proud of it, and most metrics it wouldn't reflect how difficult it was to do.

@@davidolsen1222 i work with java spring and it can take hours, sometimes days, so solve an problem that results in adding 2 dependencies, 3 annotations and 1-2 config values. I purposely choose that over my broken implementation i could whip up in an hour or 2 precisely because its more maintainable.

And if you do all that, when do you have time to develop new features? Seems to me that's the thrust of this talk: since you can't refactor everything, use analysis to find the intersection of complexity and change frequency to constrain your refactoring to the highest value refactors.

Also “start of recorded history” and “invention of writing” are not the same thing, particularly when many of the earliest written documents are land deeds and contracts. And outside of the mundane stuff it’s largely personal inscriptions by rulers AKA propaganda. Recorded history almost certainly begins with oral traditions, and I’d wager that writing was not used for “true” history for a long time after it’s invention. Not worth it if hardly anyone can read.

brb, rewriting our core app in Linear B

The tool is called CodeScene.

\uj It's nice that he is laying down some typology of code analysis. He is also asking the right questions. But yeah, the entire talk reeks of consulting companies BS. That methodology of finding hotspots seems plain silly to me. It is only adequate in a very few edge cases. Also, cyclomatic complexity is just bullshit. Anyone can spot code that smell because of silly conditionals. Apart from that, handling a lot of cases is just handling a lot of cases. Handling less cases is just having less features. Now there are techniques for reducing the amount of conditionals (composition, branchless programming, etc...) but I don't think that is the topic he was trying to explore. It really seemed like a great lecture that was eye opening. But really it's just good communication skills. I can't think of anything directly useful being said there.

@@michaelmalter2236 You can always substitute cyclomatic complexity metric for any other that you seem more viable and still follow the approach suggested. His primary insight is to use code change frequency as an important parameter to deciding on prioritization of factoring. While that is not revolutionary in thought, its certainly not BS.

Rules don't change the existing Tech debt. Only actions does. And what should you action on?

@@CA-oe1ok Rules = Actions. You can do actions before and after TD in the codebase. Code Review blocks 80% of future TD.