C_deScene Co_eScene Cod_Scene Code_cene CodeS_ene CodeSc_ne CodeSce_e CodeScen_ — because your code is worth it The cost of code: Bridging the gap between tech and business CodeScene’s project management metrics let you measure where you spend your costs and how the development activity shifts over time. This information is useful to bridge the gap between the technical side of the organization and the business side, as you let non-technical managers peek into the codebase from a different point of view. The Need for Cost Metrics CodeScene’s project management metrics answer between developers and managers here: to a two common questions: manager, the concept of a “commit” doesn’t carry much meaning. A commit is a technical term 1. How shall we prioritize improvements to that doesn’t translate to anything in the world our codebase? of managers. At the same time, technical debt with high interest rates and low quality code are 2. How can we follow-up on the effects of the important subjects to address. So how can we improvements we do? Did we really get an communicate in the language of a manager while effect out of that design improvement? still tying our data back to something that carries meaning for the developers responsible for Sure, a traditional hotspot analysis already the code? addresses these questions and gives us a tool to prioritize. However, there’s a linguistic chasm 3 CodeScene bridges this chasm by introducing point reports. We then analyze how those costs In this example, the work trend shows that there From here we can get much more detailed data a suite of project management metrics. These are distributed across the different parts of your was a burst of critical features added in April. by diving down to the file level and identifying the metrics combine our existing behavioral code codebase. This gives you Hotspots measured by Unfortunately there seems to have been several parts of the code where we spend most of our time. analyses with data from project management tools cost rather than the more technical metrics. Let’s bugs too, with nearly 40% of the development time Here’s an example: like JIRA, where CodeScene extracts time-based look at an example. spent on fixing defects. Now, if we do some focused costs (i.e. minutes of time to completion) or story refactorings we’d expect that to pay off in the future cost and work trends. Get detailed cost metrics on a file level. Calculate hotspots by costs on architectural level. You use this information to ensure that the code project management results and the results evolves in the right direction. For example, you’d from the technical hotspot analyses. This is an like to see a decrease in the amount of bug fixes expected finding. However, the main purpose of As you see in the preceding figure, the most before we dive into the technical analyses and look and an increase in the amount of features. You can the project management metrics is to provide a developer time is spent in the Web Backend sub- for refactoring targets, we’d like to inspect the work also use the cost trends to measure the effect of basis for communication. Thus, you’d use this data system. This means we want to ensure that the trends. Here’s what they look like for the code in the large-scale improvements. to motivate investments in software quality, like code is easy to understand and to evolve. If not, we Web Backend sub-system: explaining the need for a larger refactoring of a top want to prioritize improvements to that part. But As a developer, you’ll probably notice that there hotspot. tends to be a a strong correlation between the Try it Yourself The project management analyses are exclusive to our on-premise version of CodeScene. CodeScene provides an open API that lets you integrate with any project management tool. CodeScene also comes with an out of the box JIRA integration that supports costs as both time and story points. Use the trends in type of work to see where your time is spent. 4 5 Measure Conway’s Law with Codescene A knowledge map shows the main developer behind each module. Mel Conway’s astute observation that an organization’s communication structure should be reflected in the software architecture has received plenty of attention over the past years. Part of that is due to the popularization of microservices, which promises natural team boundaries where each team might be responsible for their own A knowledge map is useful to guide on- and analysis and measure on architecturally significant service. As such, Conway’s Law is an important principle that drives off-boarding, but it doesn’t really help us on our components and sub-systems, as opposed to both organizational and technical decisions. At the same time, the quest to measure Conway’s Law. But it’s a starting individual files. CodeScene solves this by letting organizational and social side of code is largely left to subjective point. Our next step is to add the organizational you specify your architectural boundaries and judgments. What if we could guide those decisions with objective data dimension by aggregating individuals into teams. teams. instead? Follow along and see how you can measure Conway’s Law. We also want to raise the abstraction level of the The Social Side of Code As soon as an organization grows beyond a CodeScene’s behavioral code analysis helps you fill handful of people, social aspects like coordination, in the blanks. Behavioral code analysis emphasizes communication, and motivation issues increase trends in the development of your codebase in importance. Unfortunately these, well, softer by mining version-control data. Since version- aspects of software development are invisible control data is also social data – we know exactly in our code; if you pick up a piece of code from which programmer that wrote each piece of code your system there’s no way of telling if it’s been – it’s possible to build up knowledge maps of a written by a single developer or if that code is codebase, as shown in the next figure. a coordination bottleneck for five development teams. That is, we miss an important piece of information: the people side of code. Assign individual developers to teams. 6 7 Using that configuration, CodeScene measures the own component in an analysis. This gives you a The preceding figure shows a system that’s fairly Behavioral code analysis helps you ask the right knowledge distribution on an architectural level by powerful tool to evaluate how well your architecture well aligned with Conway’s Law as most of the questions, and points your attention to the aspects aggregating the contributions to individual files into aligns with your organization, as shown in the next coordination needs are low. This means that there’s of your system – both social and technical – that the configured logical boundaries. For example, figure. little overlap between the contributions of the are most likely to need it. You use this information if you do microservices, each service would be its different teams. However, there’s one exception: to find parts of the code that may have to be split the Jenkins Plugin has attracted code from three and modularized to facilitate parallel development separate teams over the analysis period. This might by separate teams, or, find opportunities to be fine – a behavioral code analysis doesn’t judge introduce a new team into your organization to take – but it’s a pattern that deviates from the rest of the on a shared responsibility. codebase and, as such, might be worth to look into and understand. There’s More The way developers collaborate is crucial to the success of any system, and this blog post has really just scratched the surface. If you want to dive deeper, you might want to check out my new book, Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, which goes into much more detail with several real-world examples. Visualize in which sub-systems that each team works. The analyses themselves are completely automated, so try them out in CodeScene Cloud, which is free for open source, or check out the on-premise version of CodeScene. The previous visualization is based on the actual The same analysis also lets you measure the code contributions of each team. Each team gets coordination needs on an architectural level. This assigned a color (look at the color legend to the is useful to detect sub-systems that become right in the figure), and the team that has written coordination bottlenecks or lack a clear ownership, most of the code gets highlighted for that sub- as shown in the next figure. system. As such, the information is always up to date and you can chose how far back in time you want to go when collecting the data. Find team coordination bottlenecks based on code contributions. 8 9 Early warnings for future maintenance problems A codebase under active development evolves at a rapid pace, and These early warnings point your attention to • Identifies Steep Increases In Complexity: as soon as the organization scales beyond 10-12 people it’s virtually different aspects of the system: Since CodeScene knows how your code impossible for a single individual to maintain a holistic picture of the typically evolves, the tool can detect parts of system. The roots of future maintenance problems are often introduced • Detects Code before it becomes a Hotspot: the code that suddenly increases in complexity in change bursts, perhaps by shoehorning a new feature into an existing This warning highlights code that isn’t a hotspot as shown in the next figure.