@josda1000
This is why code really is hard to maintain... people leaving, taking their knowledge with them, but also even your own code can become "legacy" because you improve over time, but you wrote that console job that runs monthly a decade ago, and now we have to make changes because of govt regulation. So no it's not just churn that's a factor, but knowledge changes themselves. So keeping code as clean as possible all the time is an actual goal. Except for those that like to go fast without realizing their actions have consequences. Awesome talk, i love this guy.
@ncuxap12444
This encapsulates the programming experience so well. Software engineering is all about solving these issues. It doesn't matter that much what exactly is the product, the problems are the same.
@krccmsitp2884
Definitely one of the best talks I've seen the last year.
@Syntax753
This is fantastic! What a wonderful breakdown of "what matters" in tech. Measuring, ordering and actioning such a complex topic in such a visual way can only come from a genius mind at work. Nobel prize vote from me!
@nekony3563
It could be also in reverse. A large file with frequent changes means that people managed to do them relatively easily. So, this file might be not that bad. But when you open some rarely touched file to slightly modify it for your 2 story points task and after 10 minutes you start asking yourself about your life... 😄
@erikig
Thanks!
@xarz3
Sometimes we don't touch code that works because we are just too scared to break it or we just don't have enough time and resources to do so. So we don't change it, even at cost of dropping useful features we'd like to have. This is the worst type of technical debt because it totally limits your innovation and business opportunities, and this can't be identified observing the git history
@seetlive
Valuable lecture, it is a big challenge to write quality code. I've been refactoring a code base the full today, making it more resilient for future development. While I was doing so I was thinking about what could be done better to reduce refactoring in the future, writing code that lives longer.
@afnanahmad9256
WOW !!! Wonderful explanation. Each and every word is so clear. Simply awesome !
@adambickford8720
The code is a usually a reflection of the company/management. I worked at a place with a 'you build, you own' model but we were saddled with a 15 year old project where it literally used sql injection as a feature. Everyone despised working on that code. So we get the green light to write something that will scale 10x to replace it and wrote a reactive system. The work environment was so bad that the team of 5 devs quit within 6-8 months of each other with no real knowledge transfer. I promise you the guys that inherited a reactive system despise it as they won't have the benefit of a learning curve; that things in prod baby!
@JeffHanke
Thanks for the talk! I really like the idea of mining version control for data and combining that with other metrics to inform decisions on how to prioritize dealing with technical debt.
@petabrain
Offensive implementations are usually left alone because the rest of the code depend on these. I'd argue that frequency of change of offensive implementations isn't what we're after, I think the scale should be measured by uses of offensive code -- i.e. how likely it is to impact you when you're writing new code or changing existing code.
@scottnash70
Great talk, and I'd add one note to it. Adam mentions bugs as a consequence of Tech Debt. I'd take that one step further and say specifically "Regression bugs" are a nasty consequence, particularly if you've changed one part of the code base and a seemingly unrelated area starts acting up. Patches and hot fixes are particularly vulnerable because they may not have received a wide enough testing. Good companies can keep regression rates under 10%; heavy tech debt can push that over 50%.
@argfasdfgadfgasdfgsdfgsdfg6351
These metrics don't take into account that some files might have a low code change frequency BECAUSE they have so much technical debt. If nobody understands a specific file, nobody will dare to change it.
@RoamingAdhocrat
at my employer we have a weekly meeting to discuss bugs and minor feature requests raised from the service desk. inexplicably this work is labelled "tech debt"
@dananskidolf
Seeing the hotspots from the source control history is a neat idea and it would pick up some of my least favourite source files immediately. But in the interest of prioritisation of technical debt, you often want to focus on code improvements to prepare for a particular upcoming feature, which means identifying something before it becomes a hotspot, so that the new feature built on top isn't slowed down by the pre-existing code problems.
@nahuelalberti5963
What a great talk! Currently my team is planning to attack tech debt, this info is really gold!
@blarghblargh
Suitability of software doesn't strictly decrease over time. Needs can evolve, but they don't always. I would argue that most software is built under the assumption of a growth economics model, and requires the software to continually adapt in order to meet the revenue model of the company selling the software, rather than the suitability of the software to existing customers. This is something that can be pigeon-holed into the first "'law" in this talk, but the subtleties of such distinctions is extremely important if we are interested in seeking truth (the "root cause" as described in the talk). It can strongly impact the types of modifications that changing requirements entail, as well as the volume of changes. If you insist on focusing your lens to only include the code side of things, then you can't optimize the experience for existing customers. This is a reason that it's best not to bury your head as a developer.
@mariusirgens5555
Amazing presentation!
@GOTO-