Code Climate’s flagship product, Velocity, analyzes all the data from your GitHub repos and provides you with heads-up displays, real-time analytics, and custom reports to give you a clearer perspective on how your engineering team is working

Code Climate

When global circumstances required our team to go completely remote, we knew things would be tough. Team members wouldn’t just be working from home; they’d be working from home during a time of intense fear and uncertainty, with a myriad of new concerns and distractions. We expected that engineering activity would decline as a result, and we were understanding — as our VP of Engineering, Ale Paredes, explained during a panel on , “We're not trying to behave as if it's business as usual, because it's not business as usual.” But when Ale checked the team’s productivity metrics in , our engineering analytics platform, she was surprised by what she found. After we made the switch to a distributed workflow, many engineers actually started working more. Still, despite logging more time in the codebase, they were getting less done. To find out why the team wasn’t making progress, Ale dug deeper into the data. Not only did she find answers, she used that information to develop better ways to support the team. working remotely through the crisis Velocity Engineering Metrics Served as a Diagnostic Tool Ale and the engineering team regularly track certain key metrics in , using data about Pull Request Throughput, , and Incidents to get a sense of how they’re doing. They review this information on a bi-weekly basis, so they can address red flags as early as possible or replicate processes that are having a positive impact. When something appears to be trending in a concerning direction, the team drills down deeper into the data, then uses that information as a starting point for troubleshooting conversations. After the team transitioned to a fully-distributed workflow, they noticed that their Pull Request Throughput was significantly lower than usual. Velocity Cycle Time Knowing that the team was merging fewer Pull Requests than expected, Ale took a closer look at the stages of the coding process to find out why. This investigation included a look at: The time between a developer’s first commit and the opening of an associated Pull Request. If the team simply wasn’t pushing commits in the first place, it could be a sign that their attention was focused elsewhere, or that they were being sidelined by anxiety or emotional stress. If developers were coding but not opening PRs, they could be confused about project specifications. Time to Open: The period between when a Pull Request is opened, and when it’s picked up for review. A slowdown here could mean that physical distance was causing engineers to focus on their own work and deprioritize assisting their teammates. Time to First Review: The period of time a PR spends in the code review process. If PRs were getting stuck in code review, it could indicate a lack of alignment between members of the team. Time to Approve: The actual deployment process. A holdup at this phase could be the result of technical issues or a lack of confidence in new code. Time to Deploy: As she dug into the metrics, Ale saw that Time to Open was the source of the slowdown. The engineering team was clearly working — they were pushing commits, and actively coding — but they were completing a higher than usual percentage of Rework. Something was keeping the team writing and rewriting the same pieces of code, which concerned Ale. “Beyond the waste itself, which is not great, I worried that if we didn’t address the issue right away, it could impact team morale.” Improved Communication Helped Decrease Levels of Rework With this information, Ale approached the engineering team’s squad leads “to try to understand what was blocking the team, and to identify how we could work together to create a process that was more streamlined.” Through these conversations, Ale discovered that individual developers were getting hung up as a result of miscommunications and unclear specs. Though the team was having regular remote meetings, developers still lacked the information they needed to do their work. “People didn’t have the same amount of context,” Ale found. “We used to rely on the fact that we were all together in the office so that if I had something to say, the person next to me would hear it...our team is small enough that usually, everyone on the team has context.” Without a process in place for sharing this big-picture information, engineers were getting left in the dark. They didn’t always know how their work fit into the project as a whole, so they were making assumptions, some of which were incorrect. At the same time, “we noticed that people were using direct messages to communicate, so everyone had slightly different bits of information,” and developers were forced to continually revise their work as new information came to light. Armed with these realizations, Ale and the team were able to create new processes to combat misinformation and enhance transparency: Discussions were moved to a team public Slack channel, with particularly complex conversations happening in groups over Zoom. Decisions were logged in Jira, with each engineer responsible for adding relevant comments to any issues they own, so the rest of the team could reference them when needed. They created systems for intentional public communication. For each new feature, the team worked with Product to draw up a detailed spec document. These documents were then discussed at kickoff meetings for each new track of work so that everyone could see the details and ask questions. For projects that required more in-depth technical design, engineers would write a Request for Comment document and store it in markdown format in GitHub, so teammates could leave comments as part of the code review process. They leaned more heavily on documentation. Each week, the team wrote down their plans for the next few days and shared them with the rest of the team. They wrote down and shared their plans. Though she’s always done it, Ale made a continued effort to encourage senior engineers to use the team public Slack channel to discuss challenges and think through solutions, so that team members feel safer raising questions and admitting confusion. They fostered a culture of sharing. With the new processes in place, the team kept an eye on the metrics to evaluate their success. The Productive and Human Benefits of Increased Transparency The new processes helped increase transparency, reduce confusion, and boost productivity. In a span of four weeks, Rework fell from a high of 20% to just 6%. Over that same period, average PR Throughput went up almost 70%. But most importantly, engineers are now less confused and are finding more opportunities to collaborate. The emphasis on documentation and written plans offer the opportunity to ask questions at every stage of the process. And with everyone looped in, developers can lend a hand to people on other teams, something that frequently occurred when everyone was together in the office. Writing things down also has an unforeseen benefit — it’s helping the team avoid unnecessary meetings. While the team is remote, they’re using that extra time to connect on a more human level, building time into each standup to check in with each other, and carving time out of retros to talk about how they’re coping with the current situation. As Ale explained, “We were able to adapt our last retro to how we were feeling, instead of just focusing on the product process. We understood that was not what we needed to be talking about right now, that we need to talk about how we’re feeling and how we’re coping.” Ale expects the team will continue to see benefits from these new processes, even once they return to the office. Alignment has increased, communication has improved, and enhanced documentation will make it easier to onboard new team members. Plus, when the team reverts to their partially-distributed structure, they’ll do so with a greater sense of unity. As Ale explained, “We now have a lot more empathy for our remote team members.” If you’d like to learn more about how engineering analytics can help you support your team, join us for a free, 45 minute live webinar with Code Climate Co-Founder Noah Davis on Tuesday, May 5th at 1pm (EST). This webinar will focus on how to dig into engineering data from Velocity to improve the way you run remote meetings. Previously published at https://codeclimate.com/blog/how-our-vp-of-engineering-used-data-to-support-our-engineering-team-on-a-human-level/

How CodeClimate's VP of Engineering Used Data to Support Our Engineering Team on a Human Level

High-quality code is critical to creating functional error and bug-free software that is easy to edit and understand. But while we sometimes spot our own errors, we need to really dig a little deeper. Measuring code quality lets Engineers troubleshoot effectively, prioritize their time and run better . With these code quality metrics, engineering teams can see trends and patterns of the problem areas that need fixing. sprint planning meetings How to Measure Code Quality: The 7 Most Critical Qualitative Metrics Do a bunch of reading on code quality, and seven things appear consistently as a way to measure your code quality. You can ask yourself these questions that are as much about how you code as your bigger workplace priorities: Can your code be easily read by even beginner developers? Is your code extensible? Can it be edited by developers who aren't the original author? Is your code easy to maintain? How's the code for portability? Is your code well tested for quality and bugs? Does regularly updated documentation accompany your code? Is your code regularly to reduce the problem of technical debt? refactored You can create & prioritize technical issues and gradually improve your codebase quality. It’ll help you answer questions such as: Does this issue slow down your development? Will the next sprint be affected by it? How difficult is it to work with this code? Can other Engineers understand and change it quickly? How does this issue affect our customers? These metrics are impossible to automate but you can create a habit in your Engineering team to report and address technical issues on a regular basis. What About Quantitative Metrics? The 1970s were a big time for software development, and two key schools of thought emerged that aim to improve code quality by reducing code complexity, especially regarding maintainability: Halstead Complexity Measures The Measures offer an algorithmic way of identifying the measurable properties of software and their relationships with each other. These metrics include vocabulary, program length, the number of bugs, and testing time. They are primarily used to measure maintainability. Halstead Complexity Cyclomatic Complexity counts the number of linearly independent paths within your source code. The hypothesis is that the higher the cyclomatic complexity, the more chance of errors. A modern use of cyclomatic complexity is to improve software testability. Cyclomatic complexity Yes, You Can Automate That Shiz: If your eyes are blurring over as you slept through the quantitative metrics class at university, don't stress. There's plenty of tools available that help teams automate the code review process: Codacy Code Climate CodeGrip CodeScene Reviewboard Smartbear SonarQube Veracode A static code analyzer can help you highlight possible vulnerabilities within 'static' (non-running) source code, such as security vulnerabilities. keeps a great list of Source Code Analysis Tools. There's also a on Wikipedia, including tools suitable for more esoteric programming languages. OWASP mammoth list Tips on How to Improve Code Quality A survey by Smart Bear found that the number one way a company can improve code quality is through Code Review. Results also indicated that Unit Testing is the second most important at 20% of responses, followed by Continuous Integration and Continuous Testing. 2020 Code Review What's significant about the top six tasks is that they require intention (they don't just magically happen). Even better, you can largely automate them. Automating tasks makes it easy to incorporate them into your everyday work tasks rather than something that involves a mammoth undertaking to fix. Would you rather deal with tasks like and code refactoring in small increments or have to block out large chunks of time to fix them because your code smells? Has your team should have dealt with stopped you from bug fixing, and are project deadlines pushed back time and time again? technical debt legacy code Then there are things like style guides, documentation, and clear version control. How a company prioritizes these often depends on their turnover - a short-staffed team with high turnover is unlikely to make these a priority, nor training and onboarding. How to Choose the Right Code Quality Metrics for Your Team Ultimately, what metrics serve you best will depend on a range of factors. These include: The size of the team. The level of experience in your team. Passion projects (some people love code refactoring while others are happy writing documentation, for example). Company values - does your company prioritize code quality, or is it simply ship fast and fix later only if more than a handful of people complain? Time management: How often do you allocate time to work on bug fixing and technical debt. Start Tracking Code Issues and Reducing Technical Debt Many great tools help measure code quality. However, there are technical issues that affect your code quality that these tools simply can't catch. Also Published Here

7 Qualitative Metrics to Measure Code Quality that Every Engineer Needs to Know

There are lots of ways you can improve your code quality, make it easier to review and test and reduce the pain later of having to fix all of the errors. Let's take a look. You might not realize it, but you probably know when you see bad quality code. It might be written in a way that doesn't make sense, be full of errors, excessively verbose, or highly inconsistent in its use of terminology and naming conventions. Fortunately, there are lots of ways you can improve your code quality, make it easier to review and test and reduce the pain later of having to fix all of the errors. Let's take a look. What is code quality? Code quality refers to the attributes and characteristics of your code. These may differ according to your organization's specific business focus and the particular needs of your team. While there's no definitive checklist, there are broadly several things that separate good quality code from poor quality. Markers of good code: Clean, Consistent, Functional, or Useful—the code should do what it says it will do Easy to understand for users, not just its author Efficient—good code is succinct Testable—good code should be tested to be free of bugs or defects Easy to maintain Easy to build upon, reuse or replicate in the future Well documented—well written and adheres to agreed-upon standards or a style guide Image source: https://xkcd.com/1513/ Notably, all of these markers may mean different things to different people or teams. One person may find code clearly written and easy to understand, while another finds it unclear and thus hard to maintain. But it is helpful to have some parameters to work with. Documentation, code standards, and style guides As Damien Conway describes, "Documentation is a love letter that you write to your future self. Comments or notes in code are a way to provide a message to your future self on why you might have written code in a certain way. Or why a team member made a particular decision at a specific time. This also provides insights to other team members into your decision-making. Code standards are also helpful to provide uniformity in code across the team. They make it both easier to use and maintain. William Moore describes them as "a sequence of processes for a particular coding language that requires a coding format, the methods, and different procedures." A style guide provides a company's standard conventions (such as naming conventions) and other best practices within one place. It aims to ensure that code is consistent across all team members, making it easier to work with and review. It should be agreed upon by the team if you want them to actually own and adopt it and may require some training. Many companies such as , , and have published their style guides online, which can help you get started creating your own style guide. There's also plenty of programming language-specific guides— Alexander Van Tol writing for offers some great resources for Python programmers, including Python-specific style guides and linters. Google Microsoft WebKit RealPython The importance of code reviews Code reviews are of paramount importance to ensuring good code and providing a way to locate problems so that they can be fixed as early as possible. They can also ensure the consistency and reliability of the software you're building. For companies who have adopted a DevOps way of life, code reviews are par for the course and are already embedded in the process as early as possible. The earlier you find errors, the faster, easier, and cheaper they are to resolve. SmartBear Software conducted a global online over the course of ten weeks during the months of June and July 2020 with responses from over 740 software developers, testers, IT/operations professionals, and business leaders across 20 different industries. The respondents' rate code reviews as the best way to boost code quality. survey The survey also showed improving code quality as the topic business driver to influence the need for code review tools. Additionally, more than 80 percent of developers surveyed said satisfaction with code review processes is directly tied to confidence in software releases' overall quality. Besides code review, respondents cited unit, continuous and functional testing of code as among the best steps for improving quality. Continuous integration and integration were also cited as best practices for software development. In terms of cadence, roughly 63% of respondents , at least on a weekly basis. When it came to frequency and which approach used, 27% of respondents cited , and 19% noted a . participate in some form of code review tool-based code review on a daily basis weekly basis Overall code review ensures code meets the attributes that were mentioned earlier as markers of good code. A code review ensures code is efficient, bug-free, adheres to standards, and overall aims to catch problems early before problems multiply. Code reviews can be conducted in a variety of ways from manual reviews, pair programming, mentoring, and the use of shared documents for easy review. However, all of these methods can be time-intensive, and code review tools provide a way to automate the process. Tools to review code quality Most devs already use GitHub to maintain their Git repositories and are accustomed to the use of pull requests and forks to review code. There's also plenty of other tools available that help teams automate the code review process. Codacy Code Climate CodeGrip CodeScene Reviewboard Smartbear SonarQube Veracode For additional code review tools, take a look at the list compiled at . It's also worth noting that security is a key part of code quality. Geekflare Code quality and security are similar in that both types of issues can be identified with static analysis. Developers typically use static analytical methods to design and test components. In this instance, the code is not running or executed, but the tool itself executes using the source code as its input data. The static analysis enables devs to also use tooling to discover security issues early, often in real-time as they write code. The tools scan as the dev writes, then flag any security issues in the engineer's integrated development environment (IDE) or editor. By looking at dataflow paths through an application, static analysis tools can identify where an application mishandles data or code produces unintended outcomes. Static code review software also helps developers understand structure and coding standards and implement their own coding standards. As developers push code directly into production, static code analysis also validates code quality, decreases later errors, and reduces bugs. The tools can identify data mishandling within an app or when code causes unintended consequences. Code refactoring Another way to improve code quality is through . Source code refactoring turns messy, incorrect, and/or repetitive code into clean code with lower complexity. It addresses the standardization problems which can occur when multiple developers contribute their own code. Refactored code is easier to read and maintain. It's also easier to expand upon and add new features. Removing unnecessary parts such as duplications can also result in code that uses less memory and performs faster. refactoring Decreasing technical debt Poorly produced code may initially appear efficient but can result in a world of pain once it needs to be fixed. One of the advantages of producing quality code from the first instance is that it reduces . Good code may take longer initially to produce but can result in less bug fixing and refactoring and remove the long-term pain of technical debt. Good quality code makes long-term development and maintainability easier. technical debt One of the ways to increase code quality is to continuously track and prioritise technical debt so that you can make the business case to refactor the most important parts of your codebase. Conclusion Writing good quality code not only leads to higher quality software, but also greater team satisfaction. This is especially important when tools and frameworks and style guides are used to take a lot of the guesswork out of decision making, freeing developers to focus on more interesting tasks. However, maintaining good quality code is as important as writing the code to prevent the problem of technical debt. Originally published at Managing Technical Debt.

How To Improve Code Quality With Code Reviews and Refactoring

Over the last six months, I’ve learned how the best software engineers and leaders manage technical debt. I've interviewed more than 200 experts, to understand how tech debt is handled at growing software companies. I’ve discovered what many companies are missing and compiled my learnings into a simple but powerful framework, to share with you. As part of the customer development work for our new Stepsize product, I needed to understand the differences between software companies that have their tech debt under control and those that don't. Tech debt is an emotional topic and it gets people talking like nothing else—and it's a lot less controversial than politics. Just ask your local engineer about tech debt and you'll see. But you might want to clear your schedule first. In many—if not most—cases, tech debt accumulates until it creates problems that are impossible to ignore. So, you fix these problems and move on with your life. And you accept that maybe that's just how it's done. But should we really accept the results of , which find that, at the average company, 'engineers spend ~33% of their time dealing with technical debt, which crushes team morale and costs companies ~$85 Billion/year'? Shouldn’t we do something? Stripe’s research Gartner and many others have already shown us we should. that . Their research has revealed organisations who actively manage tech debt will ship at least 50% faster I don't know a single software company that doesn't want to ship 50% faster. Luckily, I did meet companies with solid tech debt management strategies. There were many light-bulb moments in these interviews. One of my favourites was when , Engineering Manager at Everlane, told me: James Rosen Consider how much time PMs spend curating the set of features to work on. Now compare this to the amount of time and effort engineers dedicate to making the business case for tech debt. Is it that surprising that close to zero engineering capacity gets allocated to tech debt? I must admit that nope, it isn't. However, I also met plenty of teams that spent a lot of time and effort managing tech debt and still went nowhere. All my research points to a simple fact. Companies that successfully manage tech debt have developed appropriate processes that are fully integrated into their usual Agile ceremonies and have become habits. These engineering teams are in control of their tech debt. They ship faster and more predictably. Their engineers are happier, their customers are happier—heck, they're all winning. It really doesn't take much to get there. You just need to be clear on how you'll deal with small, medium, and large pieces of tech debt. How to handle small pieces of debt This is the type of tech debt that can be addressed as soon as the engineer spots it in the code and it’s within the scope of the ticket they're working on. It might be something as simple as the refactoring of a function, or renaming some variable. Try to follow : Robert C. Martin’s boyscout rule Always leave the code better than you found it. These small jobs don't require any kind of planning and every engineer should feel empowered to fix this kind of debt without anyone else’s approval. We’ve already written about , but ensure it exists in your engineering team. If it doesn’t, take measures to address it the one cultural characteristic you need for a healthy codebase now. There are many tools to help you on this front. Our very own will give a code-quality score and breakdown, directly in your editor. Other code-quality tools, like or , which you can include in your CI pipeline and code review process, are great for this too. Tech Debt Metrics extension for VSCode Code Climate Codacy How to handle medium-sized debt This type of tech debt can be addressed within a sprint. It should go through the same sprint planning process as any feature work and be considered just as rigorously. That's where most engineering teams fail—remember James Rosen’s comment: ‘Is it that surprising that close to zero engineering capacity gets allocated to tech debt?’ Businesses rightly prioritise work that delivers value to the customer. And, at first glance, getting rid of tech debt doesn’t do that. But tech debt hinders your capacity to deliver value to the customer. To explicitly demonstrate how this occurs, identify debt that gets in the way of crucial initiatives, or costs the business dearly in terms of engineer productivity, or is the cause of bugs that impact the customer experience. Documenting tech debt and quantifying its cost allows you to prioritise the debt that, if addressed, will deliver value to customers—just like new features do. The engineering organisation owns tech debt. It is their responsibility to address it and ultimately make the business case for it. Unfortunately, this is where our current tools have so far failed us. Jira is a great place to manage projects, but a terrible place to track and monitor tech debt. Jake Peyser , Lead Engineer at Unqork Code-quality tools are helpful at surfacing one facet of tech debt, but they don't catch . most of the others Fortunately, . Engineering teams have limited time to deal with tech debt and they need to make that time count. Stepsize helps them capture and track tech debt from their workflow, so they can quantify its cost to the business and ultimately prioritise the most important debt. that's exactly what our new product is for Each engineer can report tech debt and its cost directly from their workflow (including editors, pull requests, and Slack). These reports all go to the Stepsize website where they are collated into ‘tech debt items’, describing and documenting issues in the codebase. Finally, each Jira ticket gets decorated with relevant tech debt items that may be addressed to more effectively deliver value to customers. No more lonely refactoring tickets that are never prioritised—tech debt and business value become truly aligned. We advise that engineering team leads assume responsibility for managing this process. They're the right individuals to stay on top of tech debt in those parts of the codebase their team owns, and to interface with the PM when it’s time to address the debt. How large pieces of debt should be handled This is the tech debt that cannot be addressed immediately or even in one sprint. The best companies I've interviewed have quarterly technical planning sessions in which all engineering leaders participate. Engineering managers are tasked with highlighting the large pieces of tech debt reported to them and making a business case for those they judge to be the most important. This process, which sounds laborious, becomes very easy for Stepsize users. Their individual contributors have already been reporting debt from the frontlines regularly. This data is consistently reviewed and groomed by each team and their leaders, who relay the large pieces of debt—along with the data necessary to understand what they've cost the business—to their engineering managers. Stepsize even surfaces tech debt for each of your Jira epics. Leadership can then use their understanding of the company's broader priorities and vision to sequence large pieces of debt accordingly. Once each large piece of debt is approved, it can be scheduled onto the roadmap, just like feature work. Engineering leadership then has all the data they need to monitor progress on each tech debt project. Takeaway Any modern software company should be able to apply this process for small, medium, and large pieces of tech debt. However, one thing will differ between each company: business objectives. Managing tech debt properly means addressing the debt that gets in the way of your business objectives. If your business is built on uptime and reliability, nuke any debt that puts them at risk. If velocity is your competitive advantage, get rid of any debt that wastes engineering time or makes it hard for new hires to understand the code. If you want to reduce customer churn, address the debt causing quality issues. Be clear about the business case for addressing each piece of debt. Because when you are, you'll ship better software, faster—and you’ll keep your engineers happy. Follow Stepsize on and check out our for more insights on managing technical debt! Twitter blog Previously published at https://blog.stepsize.com/the-perfect-process-to-manage-tech-debt/ ( : ) Disclaimer The author is the CEO and co-Founder at Stepsize

200+ Software Engineers Taught Me The Best Way To Manage Technical Debt

Continuous Delivery is the ability to ship code quickly, safely, and consistently, and it’s a necessity for teams that wish to remain innovative and competitive. It’s focused on delivering value to the user and starting that feedback loop early — the ideal state of Continuous Delivery is one in which your code is always ready to be deployed. Many engineering leaders think of as a workflow and focus on the tooling and processes necessary to keep code moving from commit to deploy. But CD is more than just a process — it’s a culture. To effectively practice CD, you need to: CD Convey the importance of CD to your team Create a blameless culture, one in which developers feel safe dissecting and learning from mistakes Facilitate alignment between business goals and CD. With the right culture in place, your team will be better positioned to get their code into production quickly and safely, over and over again. Explain why CD is important Processes fail when developers don’t understand their rationale. They may follow them in a nominal way, but they’ll have a hard time making judgment calls when they don’t know the underlying principles, and they may simply bend the processes to fit their preferred way of working. Code Climate’s VP of Engineering, Ale Paredes, recommends starting with context over process. Explain why you want to implement CD, reminding your team members that new processes are designed to remove bottlenecks, facilitate collaboration, and help your team grow. As they get code into production faster, they’ll also get feedback faster, allowing them to keep improving their skills and their code. Then, you can set that will allow you to track the impact of new processes. Not only will your team members understand the theoretical value of CD, meeting these new goals will help prove that it works. concrete, data-based goals Connect with individual team members Ale warns that when an individual developer isn’t bought into the idea of CD, they’ll “try to hack the system,” doing things the way they want to, while working to superficially meet your requirements. This may seem like it accomplishes the same goal, but it’s not sustainable — it’s always counterproductive for a team member to be working against your processes, whether those processes are designed to promote CD or not. She recommends using 1-on-1s to get a sense of what motivates someone. Then, you’ll be able to demonstrate how CD can help support their goals. Let’s say a developer is most excited about solving technical challenges. You might want to highlight that practicing CD will allow them to take end-to-end ownership of a project: they can build something, deploy it, and see if it works when they’re shipping small units of work more frequently. If another team member is motivated by customer feedback, you can remind them that they’ll be getting their work into customers’ hands even more quickly with CD. Creating a blameless culture Once your team is bought into the idea of Continuous Delivery, you’ll need to take things a step further. To create the conditions in which CD can thrive, you’ll need to create a blameless culture. In a blameless culture, broken processes are identified so that they can be improved, rather than to levy consequences. It’s essential that team members feel safe flagging broken processes without worrying that they’ll be penalized for doing so or that they’re singling out a peer for punishment. A leader can help establish that blamelessness in the way they communicate with their team members. Ale’s rules for incident postmortems clearly state that there is no blame. Names aren’t used when discussing incidents or writing incident reports because the understanding is that anyone could have made the same mistake. Convince the C-Suite Fostering the right culture on your team is essential to effectively implementing Continuous Delivery, but it’s not enough. CD also requires support from the top. If your company is looking for big, splashy releases every quarter, Continuous Delivery will be a tough sell. Frequent, incremental changes are almost fundamentally at odds with the roadmap that the organization will set out for engineering, and how it will measure success. To bring Continuous Delivery to an organization like this one, you’ll benefit from applying one of the core principles of CD: incremental change. You won’t be able to drive a seismic shift in one push. Instead, you might try Ale’s strategy and look for ways to introduce small changes so you can start proving the value of CD. For example, you might try automating deployments, which should cut back on incidences of human error and free up developer bandwidth for writing new code. Process may start you on your way to Continuous Delivery, but you won’t get far. Pair those processes with a culture of CD, and you just might reach the — the point at which each improvement yields benefits that motivate developers to keep improving. The Virtuous Circle Virtuous Circle of Software Delivery

The Importance of a Continuous Delivery Culture

On average, a software development team reworks about 26% of its code prior to release. Even after accounting for necessary changes, those wasted hours can cost a medium-sized business upwards of $4.7M a year. Still, when engineering leaders look to cut costs, they often look at departmental spending. Software licenses, discretionary expenses, and even salaries may come under scrutiny. But not all costs come with such a clear price tag — inefficiencies in the software development process are harder to quantify, but much more expensive. According to a 2017 DORA white paper, , the cost of Rework in software development is staggering, setting businesses of all sizes back millions of dollars a year. Forecasting the Value of DevOps Transformations Source: Forecasting The Value Of DevOps Transformations: Measuring ROI of DevOps , DORA, 2017. Unnecessary Rework, or code churn, is a significant source of waste across all industries. As the authors note, when organizations reduce their levels of Rework, they’re “essentially getting additional capacity without having to recruit and hire – just by improving processes.” Not only are they recouping the cost of wasted time – if they reinvest that time in the business, they’re realizing gains from those additional working hours. Though the costs calculated in the DORA report are astonishing, they’re also conservative. They account for the dollar value of wasted time, but the cost of Rework in software development extends beyond the cost of unproductive hours. Unnecessary Rework can also harm morale, which can lower productivity and make it difficult to retain talented developers. Using DORA’s formula, it’s possible to determine how much money your department is wasting on unnecessary Rework. If you can find ways to evaluate, diagnose, and reduce your levels of Rework, you can begin to make a dent in one of your largest hidden costs. Identifying Unnecessary Rework in Software Development Information about your team’s Rework is already available in your VCS. Using , you can analyze Rework at both the team and individual level and begin to observe trends. When you’re just beginning to tackle Rework in your organization, start by establishing your team’s baseline. How much Rework is normal for your team? For an individual? an engineering analytics platform You can use that information to identify teams or individuals with high levels of Rework relative to the rest of the department. It can also help you spot any general organization-wide upticks. These deviations from your baseline represent anomalies worth investigating, though it’s important to note that your investigation won’t always reveal waste. Some Rework is expected, even necessary — and in some cases, avoiding Rework for the sake of bringing your numbers down will only convert that cost into technical debt, which you’ll pay for later. Through conversations with your team, you’ll be able to put your observations in context and determine which Rework is anticipated and which needs to be addressed. Source: Velocity . Green highlights high performance, while red indicates an area in need of improvement, relative to the rest of the team. Rework at the Individual Level Let’s say you’ve identified a developer whose Rework levels are higher than the rest of the team. Check that observation against what you already know about their circumstances. If the developer is a recent hire still getting familiar with the codebase, or a team member working in a new programming language, it’s reasonable to expect higher-than-usual levels of Rework. If this number doesn’t decrease over time, you can treat it as a coaching opportunity. Rework is a leading metric, and high Rework levels can signal that additional hold-ups will appear further down in your development pipeline. Use specific units of work as a starting point, and talk to the contributor about their biggest stumbling blocks. Together, you can develop a strategy for improvement, like arranging for a pair programming session with a more senior member of the team. Rework at the Team Level You can apply the same strategy to teams. When you notice that Rework is trending upward — on one team or across the organization — use that as a starting point for conversation. It can be helpful to bring specific units of work to your retros or stand-ups, so you can kick off the discussion around something concrete. Through these conversations, you may learn that the team has been struggling with unclear technical documentation, or suffering through . From there, you can work together to address the issue. A team whose Rework is a result of poor documentation may benefit from taking some time to clarify product specs, while one dealing with a lack of communication may benefit from opening new channels for sharing information. breakdowns in communication Set Targets to Decrease Rework Once you’ve begun to evaluate your team’s Rework, you can use that information to towards those goals. Set a target that is ambitious, but achievable, for your team. If you want to get to 20% and you’re currently at 30% Rework, it might be productive to aim to get to 20% in stages, rather than all at once. set targets and track progress What Will You Do With Your “Free” Time? Cutting down Rework is more than just a cost-saving measure. It’s a chance to reinvest in your department without spending money. Time that used to go to waste can be used for innovation. Developers who were previously frustrated by their inability to make progress will be motivated by the opportunity to add value, and will be more likely to stick around. With a stable team and more hours in the day, your department will be able to make an even bigger impact. Previously published at https://codeclimate.com/blog/rework-costs-millions/

Rework Costs Your Company Millions — How to Cut Back?

Processes are essential for effective management. They keep people in sync, making it possible for team members to come together and achieve a shared goal. But they’re also dangerous. Processes can create the illusion that things are running smoothly because they’re moving along according to the shared understanding of how they’re “supposed to” run. — the idea that by adding consistency and predictability to a shared workflow, a given process is inherently valuable. Too often, process becomes canon. A team develops an effective way of doing something, then returns to that framework indefinitely, long past its expiration date. This is the Fallacy of Process As processes grow stale, they become red tape, increasing friction rather than removing it. That friction is more than just a hassle; it can be incredibly expensive — inefficiencies result in lost productivity, and frustrated developers are more likely to seek new roles elsewhere. Just as a good process can multiply your team’s productivity, a bad, broken, or outdated process can have a compounding effect, costing your department more than any line item on its budget. , Rands and co-host Lyle Troxell, Senior Software Engineer at Netflix, propose the idea that between total entropy and complete control. For a process to be valuable, it needs to live somewhere between the two extremes. On their podcast every process lives somewhere on a spectrum They suggest that the problem with process starts with attitude, and they recommend that managers: Treat each process like a living, breathing thing. Recognize that just because something works well now doesn’t mean it will in the future. Work to understand the “why” of each process — and include it in documentation. If it’s difficult to articulate why something is done a certain way, it may be time for a change. Evaluate processes frequently, and improve them when necessary. Managers at all levels would do well to heed this advice. But it can be difficult to and honestly evaluate processes when you’re not the one tasked with implementing them. Still, it’s essential — the farther a broken process strays towards one end of the spectrum, the more it’s likely to cost you. So, as a leader looking to evaluate and optimize your team’s processes, where should you start? identify sources of friction Software development pipeline model courtesy of Alexandra Paredes. A can help you get your bearings. Start big — map out how work should flow through your software development pipeline, for instance — and then share that model with your team. Solicit their feedback, and pay careful attention to any points of confusion or disagreement. If your mental model doesn’t align with your team’s assumptions, it may indicate that a process is broken or that your documentation needs to be improved. Create a Mental Model. mental model Once your mental model reflects your team’s understanding of how things work, you’ll need to confirm that those expectations are in line with reality. Engineering metrics are a powerful way to get that gut-check; about how things are going. When a metric doesn’t align with your expectations, it’s a sign that you should dig deeper and get more context from your team — you may find a process that’s ready for a refresh. Use Data to Check Your Expectations. objective measurements allow you to test your hypotheses Take your list of ineffective processes, and identify the most problematic ones. Which are the biggest sources of frustration for your team? Which cause the biggest holdups? Which have a cascading effect, causing more blockages down the line? These are your most expensive points of friction and the ones you should focus on fixing first. Maximize Your Impact. Talk to your team about your broken processes, and ask how they’d fix them. Even if you think you’ve found an obvious solution, be sure to get feedback — if your team isn’t on board with a new process from its inception, it’s more likely to become a source of friction. Draw Up A New Plan, And Get Feedback. Processes are not static. They need to evolve as the circumstances around them change. Keep looking for ways to optimize your processes, and prevent them from becoming blockers. Repeat. Continually evaluating and revamping your processes is the only way to keep them fresh and effective, and to ensure you’re not paying for processes that exist for process’s sake. Of course, there’s a certain paradox inherent in proposing a new process for fixing old, broken processes. Adapt it, change it, and make it work for you. Anything less would just be falling prey to the Fallacy of Process. Previously published at https://codeclimate.com/blog/the-fallacy-of-process

CODE CLIMATE

codeclimate.com

-- employees

Since n.d.

COMPANY RANKING

CODE CLIMATE

EVERGREEN INDEX #3346

Representing this company? Click here to claim and customize this page!

Code Climate WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

CODE CLIMATE

codeclimate.com

-- employees

Since n.d.

COMPANY RANKING

CODE CLIMATE

EVERGREEN INDEX #3346

RELATED COMPANIESRANK

STORIES ABOUT CODE CLIMATE

Representing this company? Click here to claim and customize this page!

Code Climate WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!