GOTO 2019 • Prioritizing Technical Debt as if Time and Money Matters • Adam Tornhill

[Music] so good morning everyone and welcome to this session on prioritizing technical depth this is a broad topic and I have a lot of stuff to cover for you today so I want us to jump right in and start by covering the forces we have to balance when building large-scale software systems and I do think that these forces are wery well captured in something called Lehman's loss of soft revolution so let me ask you how many of you have heard about Lehman's loss not so many that's good I got something new for you it's perfect so Lehman's law they are pretty fascinating because they are old they were written down in 1970s early 1980s and they are not that well known so I tried to do my best to popularize them and today I want to show just two of those laws to you here now so let's start with the first law and see if it resonates with your experience so the first law of software evolution is the law of continuous change will Lehman says that the system has to continuously evolve and adapt or it will become progressively less useful over time do you recognize this yeah this is the right reason where we keep adding new stuff new features to existing products because we need to keep them relevant we need to respond to competitors and user needs what I want you to do now is to note that in the second law of software evolution we have some kind of conflict some kind of tension between these two laws because the second law is the law of increasing complexity well Lima claims that as a system evolves its complexity will increase unless we actively try to reduce it so do you see the tension between these two laws on one hand we have to continuously evolve an adapter system but as we do its complexity will increase which makes it harder and harder to respond to change so this is a vicious circle that we need to break and the problem is when we fail to do that we tend to see the symptoms more than root cause and we tend to say the symptoms differently depending on who we are what our role is so what most business leaders and technical leaders tend to see is symptoms on a road map we might experience long lead times it simply takes longer longer to implement a new feature we might also note this as a consequence a lack of predictability that is it becomes incredibly hard to guess how long it's going to take to implement a particular story what our end users tend to see are symptoms on the external quality of the code they tend to see this they tend to see bugs and the real issues tend to remain largely hidden an optic so how can we shine a light on issues like code quality and technical depth well one obvious way of doing this is to start to quantify technical depth right we could simply put a number on it and see for depth grows or shrinks so this is something I've seen done many many times so as part of my day job what I do is I work with code analysis so I go to different organizations I analyze the code I try to give my recommendations and when I start to do this it's little bit more than four years ago now one of the first clients are visited they had done something pretty fascinating prior to my arrival they had used the tool capable of quantifying technical depth based on how the source code looked so they had taken this tool and thrown it at their 15-year old codebase and this tool reported that on your 15 year old codebase you have accumulated 4,000 years of technical depth now for Francaise years of technical depth I always like to put things into perspective so 4,000 years ago that was here that's the start of record and history through the invention of writing so on a side note I always get curious what kind of programming language do they use most likely a Fortran right yeah so anyway I want to point out that and well aware that those 4,000 years of technical depth it grew in parallel by having hundreds of developers work in the codebase so it might actually be accurate the question is how useful is it how do you act upon their data so this is where it starts to become dangerous because this is also something experienced in many different organizations when you try to quantify technical depth based on how the source code looks or any properties of the code but tends to happen is that the first time you do that you end up with lots of information right you may have thousands of potential problems in your code base quality sheis so how do you act upon that mass of data well the first thing that happens is that we start to look at the different categories so we might think that maybe the tool recommends some recommendations right so let's skip them went on time any time to improve something here and then we see warnings all right maybe they are not that important right so let's push them to the side and with them focused on the most severe category and even we do that I've seen lots of existing applications we're running a static analysis produces like five six seven thousand major ratios and at some point the symptoms of technical depth they tend to become too pressing so doing as Asia needs to act upon it and the way many organizations tend to act upon this is by putting our quantitative goal on it so maybe they say things like alright we have 7,000 major ratios let's invest three months into bringing that down to 5,000 and when I hear something like that I always always advise against it because to me go from 7,000 major ratios down to 5,000 you know it's a little bit like choosing to jump from their fifth instead of the seventh floor it's most likely not a good idea and the reason I say that is because we really have to consider what kind of behavior we reinforce by putting our quantitative goal on technical depth because what is going to happen well with the quantitative goal people like us developers we're going to optimize for what we are being measured on so that most likely means that we're going to pick not only the simplest tasks but we are going to pick toss that we are comfortable with that we are familiar with and that also means that we lack the most important aspect of technical left we lack the business impact there's no link to the business impact in a quantitative goal so I think that trying to put the quantitative goal on technical depth I think it's actually dangerous right in the best-case scenario you're just wasting time but what's more problematic is that you miss an opportunity to invest your time into doing something that could really really have an impact on your business so what I want to show you now is that quantifying technical depth it's possible it might be interesting it's most likely the pressive but it's not actionable and okay this is going to be interesting no tweets please yeah all right so trying to get back on track quantify technical depth is not necessarily actionable and at the same time it's really important because we need to oversee this trade-off when we need to balance improving assisting code versus adding new features right so it's an important topic that we need to stress but how do we do it how do we prioritize it well those of you who might have been to one of my previous sessions or maybe even read one of my books you know that I'm a big big big big fan of version control data I know we all have our hobbies right this one is mine and the reason I'm so fascinated by version control is because version control data is a wonderful data source and I find it so fascinating that in the software industry we have been using version control for decades and we have used this mainly as some kind of over complicated backup system and occasionally as a collaboration tool but in doing so we have built up this wonderful data source so what I'm going to do today is to show you some case studies and how we can apply version control data to prioritize technical depth and I want to start by showing your system a real word code base that I think a lot of you might actually carry around in your pocket as I speak I'm talking about this I'm talking about Android more specifically I want us to look at the part of Android known as the platform framework base so the platform framework base in Android it's a big big code base right 3 million lines of code lots of developers and the visualization you see here is something I call a hotspot analysis so I want to walk you through this so you know what you see the first thing I want you to focus on are those large blue circles you see the ones that link on screen there each one of those represents a top level component a top-level folder so this is a hierarchical structure that follows the folder structure of your code now it's also interactive so we can zoom in to any level of detail we're interested in and when we get to a lowest level we see that each file with source code is represented as a circle and we see that the circles have different size so let's have a look at those dimensions so the number one hotspot in android right now is something called an activity manager service isn't that a beautiful name right let's consider that for a moment right activity could be something from the problem domain but then we have two more or less non descriptive words manager and service that each one and isolation indicates a unit with low cohesion and will combine them right I'm curious what we're going to find inside this one because we are going to look into it now let's get the dimensions here you see that the files have different size the circles that's because size is used to represent code complexity now how do you measure something like code complexity that is how hard is that code for human to understand well you might have heard about things like cyclomatic complexity how stats volume metrics and truth is you can use any of those metrics that you have easy access to because what they all have in common is that they're equally bad it turns out if you look at the research just controlling for the number of lines of code means that those more elaborate metrics don't add any further predictive value so what I tend to use is just the number of lines of code because this let me repeat it this is not the important dimension when prioritizing technical depth and the reason I say this is because code complexity has this property that it code complexity is only a problem when we need to deal with it right so we need to figure out all right we have some potentially complex code do we actually have to work with it and this is data that we can pull out of a version control system we can look at things like the change frequency how often do a developer go into that code and make a modification to it and we can simply count the number of commits and in the technical depth terminology I like to view code complexity as a principle that's the loan we have taken on however the change frequency that's what I use as a proxy for interest rate and when we combine these two we're capable for dint fiying hot spots that is complicated code that we have to work with often so at this point we need to dig a little bit deeper and actually look at the code and what I tend to prioritize when talking about technical depth are a number of predictors of code that's not only going to be expensive to maintain but also at risk for the effects and what I tend to find and what I tend to look for are things like cohesion right if you have too many responsibilities stuffed into that module it's going to have many reasons to change and as a consequence it's going to attract many different developers which might lead to coordination issues in that code also look for certain low-level patterns like for example deeply nested logic right you know if statements inside if statements inside if statements do you know how many percentage of all the effects come from the constructs like that alone roughly twenty percent right so I tend to look at the code and I try to form an opinion if this is a likely to be a big problem in this case I can spoil it and say that yes that code takes all of those boxes so what I do next is that I try to figure out all right maybe this code is a hotspot the cost organization already knows about it so maybe the developers are doing a lot of work in that part of the code because they're refactoring and improving it to answer that question we can use a different technique that I call complexity trends so what I do here is to simply go to their birth control data and I pull out each Easter egg revision of that piece of code and then I measure the code complexity typically using in one of the simpler metrics like cyclomatic complexity or nested logic something like that and plot it over time and for reference that's the red line the blue line is simply the accumulation of lines of code so when view this graph we see that the number of lines of code seems to grow steadily which might be a problem in itself but it's definitely a worry worrying sign when the complexity seems to increase at an even steeper rate so what this means if we take a step back is that we have a piece of code that we need to work with all the time that code has some quality problems and when we work with it it gets worse and worse and worse so this is the kind of code we need to act upon now let's put some numbers on it the activity manager service hotspot consists of roughly 20,000 lines of code it had 74 developers contributing to the same file just over the past three months at the same time we did saw that previous slide indicated that this is code that we really should reflect the right that's likely to be a very big payoff here because we work with it all the time so who would like to have that refactoring task a few brave souls that's good I would actually advise against it because I think it's dangerous to take on refactoring and read the science at that scale because what's very likely to happen is that if you look at that second number it's it's nothing to do with the code but look at the number of developers touching that code so it's going to happen if we decide to refactor this they are going to branch out you're going to work on that branch for two months and you're never ever going to be able to deliver it back because in the mean times your colleagues have been adding lots of new features to the code right remember the law of continuing change so we need to do better we need to come up with much more specific refactoring insights and to do that I use a technique I call hot spots x-ray so what I do here is that when I come across a large hot spot like that I take it that code and a parse it into separate functions and methods then I look at the version control data and see where do each commit it over time and I sum it up and I get hot spots on a function level let's have a look at that let's do an x-ray of activity manager service now this is what I tend to use to select the first prioritized refactoring and in this case we see that the hot spot on a function level inside activity manager service is a method called handle message we see that handle message has been modified 96 times just over the past year so roughly twice a week some of the developers inside that code if we look at the lines of code of that method we see that it consists of 500 lines that's a lot for a single method isn't it it is it is but it's much less than 20,000 lines of code which was size of a total hotspot and it's definitely less than three million lines of code which were sized to a total code base so more important we are now on a level where we can start to act upon this information and do a focused refactoring based on data from are we as an organization actually works with the code so I want to show you some statistics to explain where hotspots work so well to prioritize technical depth the main reason they work so well is because all code really isn't equal so please have a look at the following graphs this is some of the most important data I'm going to show you today what you see here are examples from three different systems but they all show the same kind of data on the x-axis you have each file in the system and those files are sorted according to the change frequency that is how many commits so much work can be done in each one of the files and the number of commits is what you see on the y-axis now if you look at those free examples you see I've used an example some free completely different code bases targeting different domains within different languages but different developers different organizations different life time span everything is different and yet they all show exactly the same distribution they show a power-law distribution and this is something I found in every single codebase that I've ever analyzed and a problem analyzed around 250 300 code bases but now so this seems to be the way that software evolves and this is important to us because what this means is that most of our code is going to be here in the long tail so it's code that's rarely if ever touched so unless we have some very specific contextual knowledge spending time refactoring code in the long tail is usually not a good investment in the short term most of our development activity around our hand is going to be in a very small part of the code base at the head of the curb and that's what hotspots do for us they help us identify those intersections between high development activity and technical depth at odd spots do one more thing for us and what they do is to help us put code quality into context and last year I published a book called software design x-rays and I want to show you my favorite chapter of that book I'm really happy with the title here I claimed that your best bug fix is time and what I did here was that I looked at some research and what the researchers have done is that they simply looked at different modules that solve similar problems and then they looked at the age perspective and they found out that code that's been stable for one year has roughly one-third fewer defect the facts than code that has been modified recently and this is fascinating because what it means to us is basically that from a quality perspective from the external quality perspective old code is good code and the reason I say that is because code grows old for two different reasons first of all it might simply be that it it's unused right it's dead code and that code is some of the best code you can have because you can simply delete it right it's always a win to delete code or code grows old because it's stable maybe it's still hard to understand it could be potentially hard to maintain but what is there is likely to have been debugged into functionality it's been battle tested it's been proving it and you use and it just were and using hotspots you can ensure it stays that way because hotspots help you sort your codebase into stable parts versus the more volatile parts so that you can focus or limit the time on the parts of the code where you're likely to have the largest effect now when we talk about technical depth we also need to touch up on legacy code I have found that quite often those two concepts are used interchangeably but legacy code is something different technical depth is not legacy code so let's take a step back and see what legacy code actually is and the definition I use for legacy code consists of two different parts because I view code as legacy if that code lacks in quality to some degree and more important we didn't write ourselves if we take those two boxes what we have is legacy code now let me share a story with you so this is something that happened maybe one and a half year ago I did some work with a client and I got on site and I work with one of their teams and that team they were responsible for two different code bases so we need a hot spot analysis on them and we start to review the code we start to discuss the design and what we found was that both of those code bases they looked pretty good because those hot spots any one of them that we picked up it looked pretty good right easy to follow easy to extend wonderful so everyone was happy but then someone shared the information that you know what we actually have one more code base error that we are responsible for so I said ah perfect let's bring it up and do a hotspot analysis so that one too yeah but you know it's it's a complete mess I said how even more interesting right let's bring it up and let's have a look at it so we did so we did a hotspot analysis of code base number three and guess what I found it looked really really good it looked as good as the two other codebases there was virtually no difference in terms of internal equality and this was surprising to everyone there me included until we realized that what had actually happened was that those two code bases the first more - they were written by the team themselves the third one that one was implemented by a different part of the organization a different apartment and this team have simply inherited that code so the reason that code was deemed as complicated and hard to understand had nothing at all to do with any properties of the code it was just unfamiliarity and this made me thinking that ease of understanding is also about system mastery how well duh do we know our code and that got me thinking how quick can we take our current code base and turn it into legacy code what do we need to do let's find out by doing a case study before I do that case study we need a way to reason about system mastery and knowledge distribution and what I'm going to use now is that I'm going to return to the gate logs because looking at git we can get this kind of social data we can simply identify the main developer behind each module and the main developer is simply the person has written most of the code and we can sum that up right so let me show you a different code base we rip through our java code base let's have a look at our net code base so this might be a code base that a lot of you are familiar with as users this is asp.net core NBC from Microsoft is anyone using that framework right now are lots of you like 10% maybe cool so in speed of not embassies of simply a framework for Microsoft for building dynamic web applications and the visualization you see here it's the same results asian-style as we used for the hotspots it's something called enclosure diagrams but now the colors carry a different meaning because blue simply means that these are parts of the code that's written by people who are currently contributing to that code base so people are now part of the team the different shades of grey those are our black holes in terms of system mastery so these are parts of the code where the main developer no longer works for us right and what I did now was that I identified one main contributor to that codebase a single person a person who works for Microsoft full-time on that codebase not pretended what's going to happen if that single person leaves I mean after all there are like 180 contributors in total so for sure a single person shouldn't make that big a difference well let's have a look at the visualization to the right see the red areas there that's the part of the code where we lose the majority of the detail knowledge if a single developer leaves should we be worried yes we should and this is not a fluke this is something I see consistently across many many code bases in the industry the interesting thing is that once we start to measure and visualize it like that we can actually use this data proactively so let's say this happened let's say that that person I just made up that scenario for all that I know that person is still contributing but let's say they were really going to live what I wouldn't do in that case if this was my project my code base is that I would use the time that I have left with them maybe they have two weeks one month until actually leave so what I would do is first of all I would look for entire of packages where we tend to lose the knowledge so in this case you might see here there's a package called integration tests where we seem to lose the mayority of the knowledge I don't know maybe integration tests are important to us if that's the case what I would do is I would look at the other people who have written rest of the code and I would talk to them and would check or you're comfortable in taking over the maintenance and ownership of this package what I would also do is that I would start to correlate this social data with our technical metrics in particular I would start to look for hotspots where we lose knowledge because a hotspot is a signal of relevance so if it's a hotspot it means it's very likely that we will continue to work with that part of the code and it had some quality issues then that's a big off-boarding risk to us so what I would do if I find stuff like that like an abandoned hot spots is that that will pair together the person living with someone that's gone staying and I would have them refactor that hot spots together so that we mitigate an upcoming of boarding risk so what offense of fascinating about this is that there's so much more to code complexity than just properties of the code and in particular only social factors like knowledge distribution a system or three they influence how we perceive a code base and in particular we tend to overestimate the complexity of unfamiliar code now I have much more stuff that I want to share with you but before I do that let me share the kind of tools I used to do this kind of analysis in case you want to try it on your own code base now you have to remember this is a still a pretty young field when I start to do this kind of analysis maybe nine ten years ago there weren't any tools available that could do the kind of analysis I wanted to do so to write my own and I open sourced my first tool suite it's available my github page and I still do the occasional maintenance of it is called code matt it's completely free and could do most of the analyzes that i show you today what I'm working on right now is something called a code scene so code sin is an automated service for all of this it's entirely free for open source projects so if you work in that space consider to have a look at it and support it now what I also find so fascinating is that you can get really really far with just a git client and there I have many examples in my book but I want to show you my absolute favorite did you know that with git log and a minor self flag you can specify a function inside a file and have it traced evolution of that function that's basically like an simple x-ray directly from your command line now you're going to get the links at the end as well for now I want to scale up some of the stuff we have talked about and see how we can analyze technical depth and non-code properties in micro-services so let me ask you how many of you work on a micro service system so it's like maybe 20 percent maybe it's a significant chunk a fund is really really fascinating because when I start to work with code analysis four years ago most organizations that are visited they had some kind of legacy migration plan they were talking about micro services they have started to do the first explorations but almost no one had them in operation today micro services or mainstream and this is interesting to us because what it basically means is that tomorrow's legacy systems are going to be micro services so let's stay a step ahead and see how we can make sense of micro services now when applying these techniques that I've shown you to micro services we tend to run into a number of challenges some of them are practical like micro services they are written to be polyglot code bases right they also tend to be distributed in multiple git repositories but those are pretty easy to address and I'm going to show you how it looks soon what I find more fascinating is that in a micro service architecture the most important aspects are not necessarily properties of the code but properties of the system what do I mean by that well what I mean is that in a micro service architecture code quality definitely matters it does in all systems but what's even more important or what does the connections between the services look like how do they communicate and collaborate and also what does the people's eyes look like what does the team coupling look like do we have dependencies between people so let's see how we can address that and let's start by having a look at the system called spinnaker so spinnaker is a continuous delivery platform developed by Netflix and now Google it's a micro service system and it consists of approximately 45 different git repositories each one of them encapsulating one or more micro services and what you see here is a hotspot analysis of spinnaker so each one of those top-level bubbles is now on an entire service right separate get red bow and the way I do this in practice is simpler I run a hotspot analysis for each one of the git repositories and then I just combine them in the visualization another thing I want to point out and this is also why I'm such a big fan of version control it's that spinnaker is implemented in many different programming languages seven different languages and a fascinating thing with the hotspot analysis is since it's used it uses version control later it's actually language neutral so we can visualize hotspots even in polyglot systems and get a holistic overview of them however I have found that in micro service systems and we can of course use this to identify hotspots right we see a big one there to your left but I have found that in micro service systems the interesting unit interesting level of analysis tends to be the service boundaries so what I tend to do is I take all contributions to a single service and I simply sum them up and visualize hotspots on the micro service level so this is data that we can use to detect services that seem to grow too complex like Dec here which might be an indication of low cohesion and maybe too many responsibilities stuffed into a service so this might be a starting point but I do think that we need to do better because a hotspot analysis won't help us in answering what's happening between the services what about their boundaries so we need to do a dependency analysis for micro services and this is our dependency view looks between the micro services in spinnaker and I'm going to show you how I do this calculation we're going to return to this graph in just a minute so how do you get the dependencies between microservices they are located in different git repositories right there's usually no direct communication depends in between them they tend to be decoupled by networks and message buses and whatnot so what I use is I look at coupling based on a collective intelligence of the contributing developers I use a concept called change coupling so we'll change coupling what I do is a simply look at when we implement a new feature what kind of stuff has to be might be modified in order to fulfill that feature and in this example you see a simple system with just three different micro-services we see that when implementing new features the subscription service and sign-up service tend to be changed together so if this is a trend that would continue then I note that there has to be some kind of relationship between a sign-up service and a subscription service because they keep changing together right so this is what I did for spinnaker as well so the dependencies you see here are the dependencies of change it's the impact of change is to change coupling now how do you read this data well the different labels that you see each one of them represents a service and the connections between them represents the change coupling the colors of the links represents the trend so red in this case shows a change capting dependency that is growing stronger right so that coupling is stronger now than it was a month ago and when interpreting this data I see that there seems to be a cluster of microservices in the upper right corner that tend to be changed together but what immediately draws my attention is this connection between bakery and Rosco whatever those micro services are and if this was a system that was under my responsibility what I would be interested in was to find out what does the team demand should look like because it's a big difference if those two services are owned by the same team or if they are developed and owned by two independent teams because in the later case what this would mean is a lot of potential coordination and communication overhead in particular since that dependence is increasing in strength and by uncovering this we can start to answer one of the most common questions I get when I talk to clients and that question is should we use component or feature teams you know we kind of tried both and none of them really seems to work so the reason for this it's because in an architecture with tight coupling we try to change coupling between different parts of the codebase if we try to go with something like component or domain teams what tends to happen is that we get very very long lead times it simply takes a long time to respond to change because we need to coordinate across the team boundaries so maybe we decide to switch to feature teams instead and again in a tightly coupled architecture what tends to happen with feature teams is that the whole system turns into gigantic coordination bottleneck which is an even worse problem to have and I don't think there's an easy fix to this because I think that the question of component versus feature teams it's simply the wrong question to ask because we cannot fix what is fundamentally an architectural issue with organizational changes so what do we need to do instead well we need to strive for locality of change so let me try to explain that by reading one of the best quotes I know about this subject it's from a new book by Jean Kim called a Unicom project really good book you really recommend it and in that book Jean Kim says that simplicity is important because it enables locality and locality in our code is what keeps system loosely coupled enabling us to deliver features faster so what's fascinating about this is that locality of change it's not just a technical property it's something that's fundamental to the business as well its locality on all levels that help us meet fingers do things like time to market to explore new features to do experiments and locality of change implies an alignment between our architecture our organization our teams and the business problem we are trying to solve and using a change capping analysis like that we can identify dependencies that violate the locality of change principle now once we have identified those so here we have Roscoe and bakery for example once we have identified those we need to dig deeper and make this information actionable and try to find insights into why does this happened and so far I have ripped through a number of open-source code bases so I think it's at this point it's only fair that I start to criticize my own code so let's have a look at the system I worked with a couple of years ago this is part of what later became codes in so what's fascinating with change coupling is that you can do it in any level of detail you want and what I do when I find a dependency between different architectural elements is that I do the same change capping analysis on a file level and again we are in version control wonderland so we can do language neutral analyzes so in this case we see we have a dependency between a piece of code implement in JavaScript part of the front-end that changes together with some closure code running on a back-end now when I saw this and did this analysis the first time I get surprised and the reason I got surprised is because I happen to know that the code is actually structured this way there is some distance it's a kind of architectural distance between the two units that change together one of them is front-end code in one gate repository and the other one is part of the actual analysis stuff that pulls out data from git and does some calculations on it but as you see there is some architectural distance between them so this was surprising to me and as you know surprise is never a good thing in a software architecture right might well be one of the most important most expensive things you can put into it so what I did when I found this was that in order to make this actionable I wanted to figure out okay so I know this relationship between the files but what functions actually change together so I did an x-ray and now says here as well and I want to show you how it looks so what I found here was a JavaScript function that changed together with simple specific function in their closure back-end and what I found so fascinating was that when I looked at the code I figured out that the backend code what it did was actually took some data from get did some calculations on it and then it populated a result structure and each time I added something to that result structure I had a predictable change in the user interface as well to visualize it so I know what you're thinking not really a price winning design maybe not so I focus on myself and I thought how can I avoid having those two files coupled to each other the lifetime is coupled so forth maybe we can do something like you know like composite your eyes maybe we can have some intelligent view models that kind of knows how to render themselves and yes we could and if we would implement that that change dependency would actually go away but I don't think that's the right approach because I think by doing that we would again be patching our symptoms and of the real root cause and the reason I say this is because what we have here is a worried classic dependency it's a classic producer-consumer relationship right so it's very common and when I think about it a little bit deeper I kind of realize that those two modules the reason they are kept in separate repositories the reason they're implemented in different programming languages is entirely accidental one of them happens to be code that executes in a web browser so we want it to be JavaScript and the other one is something that executes on a server but that separation is purely accidental it has nothing at all to do with the actual business problem we are trying to solve so I thought what about putting them together let them be part of the same logical component and enable locality of change so I want to leave you with the fact here before I take questions because I do think that in a time to come we need to take this stuff and let features Drive architectural building blocks not technology and if we managed to align the boundaries in our architecture of the concepts from the problem domain then we're enabling locality of change which in turn benefits not only lead times but also things like teen coupling and teamwork so locality of change is an enabler and I do think that behaviour code analysis and these techniques for prioritizing technical depth have a place here because they give you insights that you cannot get from the code alone if you look at the code we cannot see change coupling we cannot see social properties and we really really need them to be able to scale up with our systems so the main use case I see for this analysis is that they don't necessarily solve any direct problems what they do is that the help us focus our expertise and our attention to the parts of the system they are likely to need it the most and if you want to read more on this I have my new book software design x-rays I blog regularly at temper calm and Adam Thornhill calm and I'll be hanging around for today and tomorrow so if you have any questions after the talk and be more than happy to discuss it with you now I just want to take this opportunity and say thanks a lot for showing up at my session thanks a lot for listening to me and may the code be with you thank you [Applause]

Channel: GOTO Conferences

Views: 34,181

Rating: 4.8895025 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, GOTOcph, GOTO Copenhagen, Adam Tornhill, Legacy, Developer Productivity, Technical Debt, Teams

Id: fl4aZ2KXBsQ

Length: 44min 46sec (2686 seconds)

Published: Fri Dec 13 2019

Reddit Comments

[u/casual__addict]

Will have to finish this later but from what I’ve seen so far it’s a great talk. He doesn’t harp on one idea but takes on the issue of technical deBt in an encompassing and insightful way.

[u/mto96]

This is a 45 minute talk from GOTO Copenhagen 2019 by Adam Tornhill, author of "Your Code as a Crime Scene". The full talk abstract has been pasted below, give it a read before diving into the talk:

Many codebases contain code that is overly complicated, hard to understand, and hence expensive to change and evolve. Prioritizing technical debt is a hard problem as modern systems might have millions of lines of code and multiple development teams -- no-one has a holistic overview. In addition, there's always a trade-off between improving existing code versus adding new features so we need to use our time wisely. So what if we could mine the collective intelligence of all contributing programmers, and start to make decisions based on information from how the organization actually works with the code?

In this presentation you'll see how easily obtained version-control data let us uncover the behavior and patterns of the development organization. This language-neutral approach lets you prioritize the parts of your system that benefit the most from improvements, so that you can balance short- and long-term goals guided by data. The specific examples are from real-world codebases like Android, the Linux Kernel, .Net Core Runtime, and more. This new perspective on software development will change how you view code.

What will the audience learn from this talk?

• Prioritize technical debt in large-scale systems.
• Balance the trade-off between improving existing code versus adding new features.
• Learn to measure long time trends in technical debt.

[u/ScientificBeastMode]

I will have to actually listen to this talk later after work. But I am interested to see if he addresses the issue of technical debt in “agile” projects. From the description, it looks like the focus is on large enterprise systems. Yet we deal with tech debt every day in our small, agile web-dev service company.

The problem is related to the agile methodology in general. Each backlog item must be discussed and mutually agreed upon between the team and the client. But it’s always a hard sell to spend weeks working on code improvement, even when we all know that it will be better for the long term.