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

codeclimate

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

This Slogging thread by Arthur Tkachenko occurred in slogging's official #programming channel, and has been edited for readability. Arthur Tkachenko Mar 27, 2022, 11:05 PM Today I want to introduce a simple module for parsing CSV files Arthur Tkachenko Mar 27, 2022, 11:25 PM Recently I was exploring my old repository: https://github.com/Food-Static-Data/food-datasets-csv-parser Arthur Tkachenko Mar 27, 2022, 11:26 PM Inside I have a cool set of small modules, that helped me a lot. As my code is highly tied to those packages -> I need to pray for developers that build them, so I don't need to spend precious time. List of modules that I'm using: csv-parser fs lodash path path-exists shelljs Arthur Tkachenko Mar 27, 2022, 11:27 PM Why did I create this package? It's simple. During our work @ Groceristar, we came around a number of databases and datasets, related to "food-tech". To be able to extract that data and play with it -> you need to parse CSV files. Arthur Tkachenko Mar 27, 2022, 11:27 PM Arthur Tkachenko Mar 27, 2022, 11:28 PM Arthur Tkachenko Mar 27, 2022, 11:28 PM Arthur Tkachenko Mar 27, 2022, 11:29 PM Arthur Tkachenko Mar 27, 2022, 11:36 PM Link to the repository: Link to npm page: https://github.com/Food-Static-Data/food-datasets-csv-parser https://www.npmjs.com/package/@groceristar/food-dataset-csv-parser Arthur Tkachenko Mar 27, 2022, 11:44 PM I will also post updates about building modules for static data on indie hackers. While it didn't help with promotions a lot, founders are pretty positive people and their support really matters. Here is an org that I created few years ago: https://www.indiehackers.com/product/food-static-data Arthur Tkachenko Mar 27, 2022, 11:45 PM As usually, experienced developers might tell me that I'm stupid and CSV parsing is a mundane procedure. But I don't care. I realized that for a few separate projects we are running similar code. So I decided to isolate it. I did it a few times before I finally find a way to make it work as I like. And you can see how it looks right now. I can say, not ideal, but it was working fine for me. Right now I plan to revamp this package a little bit, in order to make it work with the latest versions of rollupjs and babel. Arthur Tkachenko Mar 27, 2022, 11:50 PM Arthur Tkachenko Mar 27, 2022, 11:58 PM While the idea is simple: connecting a dataset in CSV format, parsing it, and exporting data as you need it, while you need to make it work with 10 different datasets, things arent as easy as they sound in your head. CSVs not only related to food tech datasets. But for me was important to be able to use different datasets and easy to play with it. It makes other modules that we are building data-agnostic and more independent to a database/frameworks/logic. Basically, around this idea, we created and optimized like 13 repositories. Recently I created a separate organization that will be focused on those repositories only. Link: https://github.com/Food-Static-Data Later I plan to remove some repositories when they wouldn't be replaced by other, more popular, and stable tools. This current module can be useful for parsing other datasets too. But making it separate from the food tech topic isn't my task at this point. Arthur Tkachenko Mar 27, 2022, 11:59 PM And I was able to include and implement cool and important packages, like husky and coveralls. I can't say that I get most from them, but at the same time, it helped me to jump into the "open source ocean" that related to the GitHub rabbit hole that I'm still exploring for so many years. Arthur Tkachenko Mar 28, 2022, 12:00 AM and it's good to not just type another line of code, but also be able to see that your codebase is solid and nothing breaking it behind your back Arthur Tkachenko Mar 28, 2022, 12:02 AM Arthur Tkachenko Mar 28, 2022, 12:02 AM CodeClimate( ) helped me to explore and be able to take another look at how to develop things. https://codeclimate.com/ Arthur Tkachenko Mar 28, 2022, 12:03 AM Arthur Tkachenko Mar 28, 2022, 12:04 AM Arthur Tkachenko Mar 28, 2022, 12:05 AM Arthur Tkachenko Mar 28, 2022, 12:07 AM Yeah, codeclimate shows that I have code duplicates and ~50h of tech debt. Looks like a lot, right? But this is a small independent package. Imagine how much tech debt has your huge monolith project. Years of wasted time of developers, probably 🙂 Arthur Tkachenko Mar 28, 2022, 12:07 AM At some point i'll remove duplicates and it will reduce number of hours on this page. Arthur Tkachenko Mar 28, 2022, 12:10 AM Plus, usually, your product owner or CTO is busy and can't review code and be able to track things inside your code. CodeClimate can do some stuff for you. Just check those settings. Plus, they support open-source movement. So if your code is open and located on GitHub, you can use it for free. Arthur Tkachenko Mar 28, 2022, 12:14 AM Stretch goals are simple I want to invest some time into CI/CD stuff. At this moment i'll pick Travic CI. At some point i'll extend it, so when a new version of this package is published, i'll run it against our datasets and will see if something breaks or not. I also need to remove duplicated code that i was moved into separated packages but still present here, due to back capability. and it's also not cool to see JS code with all there csv files at the same repository. I need to came with idea about how to organize folders and make it easy to navigate. While it works for me - other people might find it very confusing. Arthur Tkachenko Mar 28, 2022, 12:17 AM We even did a great readme file with an explanation of how to run this package We collected a great number of datasets that can help a wast number of food projects. Some of them even sell the latest updates for money. Right now this module was tested with: - FoodComposition dataset - USDA dataset(i pick 4 major tables with data) - FAO(Food and Agriculture Organization of the United Nations) dataset This module is not just for parsing data, we also have a need to write files in JSON format with formatted data inside. Arthur Tkachenko Mar 28, 2022, 12:18 AM Show some love if you want more articles like this one! any activity will be appreciated. Arthur Tkachenko Mar 28, 2022, 12:18 AM Similar articles: - - - - https://hackernoon.com/introducing-a-simple-npm-module-with-email-templates https://hackernoon.com/how-i-started-to-build-react-components-for-email-templates https://hackernoon.com/organizing-an-advanced-structure-for-html-email-template https://hackernoon.com/open-sourcing-regular-expressions-for-markdown-syntax-module

Introducing a Simple Module for Parsing CSV Files

Gathering context and showing empathy may be the most difficult parts of a performance review, but they’re also the most important — this year, more than ever. Even in the best of times, . In the era of COVID, with team members already contending with external stressors and , a poorly-executed performance review is likely to be even more damaging to your team members’ morale. performance reviews can be harmful verging on burnout With a little extra care, leaders can avoid giving a review that focuses on business goals at the expense of the individual — and hopefully, can take a few additional steps towards boosting their team members’ motivation and well-being. After working with 1000s of engineering teams on improving performance, we've learned a few things about successful end-of-year reviews. We recommend that reviewers: Take measures to check assumptions Assume best intentions Contextualize the limited information available Be specific and Focus on coaching opportunities These strategies will help you give an effective yet compassionate review, and are worth keeping in mind any time you need to give constructive feedback. Check Your Biases and Assumptions With Data Most managers are that can hamper their ability to fairly and accurately evaluate your team members. But awareness isn’t enough. The most effective way to reduce bias is to . aware that they have innate biases check your instincts against objective data For example, performance reviews are particularly subject to recency bias. The last few weeks or even months of work loom largest in your memory, which means they are most likely to influence your opinion about your team member’s performance, even if they represent a small sliver of the past year. If your team member has been writing fewer commits than usual over the last month, you might remember them as writing less code for the entire year, Objective data can help you check that bias, as a quick look at your team member’s Commit Volume for the past year can confirm that their current drop in productivity is temporary and not representative of their performance as a whole. even if that is not the case. You can use data to check other assumptions as well. Let’s say one of your team members has been taking afternoons off to supervise remote learning or to care for an elderly relative. You might fall prey to negativity bias, a universal bias in which negative impressions — in this case, your team member’s truncated working hours — make a larger impact than positive ones. As a result, you might overlook your team member’s positive contributions to the team and assume that they have been less productive because they’ve been working fewer hours. But with objective data, you’ll know for sure. You might check their Pull Request Throughput over the last year and find out that, in fact, your team member has been just as productive than usual, if not more, because they’ve been hyper-focused during their limited working hours in an effort to get everything done. Put Everything in Context Of course, data doesn’t tell the whole story. It’s always important to put all quantitative data in context, but it’s particularly important now, when . With the right context, you can get a more complete picture of your team members’ circumstances, and gain a better understanding of their current needs. everyone is in need of a little extra compassion and support Let’s go back to the example of the team member who has been writing fewer commits than usual over the past month. It might be helpful to use that information to start a conversation and find out why they’ve had a hard time getting into the codebase. You might find out that schools in their area recently shut down, and they’ve been struggling to get into a new routine with the added responsibility of supervising remote learning. With that information, you can develop a plan to better support that team member, whether it’s temporarily taking some work off their plate or offering them a little time off until they can get their bearings. On the other hand, your conversation might reveal information that has nothing to do with their personal circumstances at all. For example, you might find out that the team member who has been logging fewer commits has been taking time out of their workday to help with onboarding new team members and improving process documentation. With that knowledge, you can have a more targeted conversation about your team member’s interests and professional goals. If it turns out your team member prefers working with new developers to writing new code, and find more opportunities for coaching and mentorship. you might be able to help them reshape their role And don’t forget — positive data needs context too. You might be pleased to find that a team member has been more productive than ever over the past year, with a consistently high Commit Volume and PR Throughput, but it’s still worth having a conversation about why that is and how it’s impacting them. That team member might reveal that they’ve been feeling overwhelmed and insecure due to the current economic and political climate, so they’ve been taking on extra projects and working long hours to ensure their job security. As their manager, you can use this information to help reassure your team member that their contribution is valued and to help take some of the pressure off. You might even want to discuss their priorities and reallocate certain tasks, so you can help your team member avoid . burning out Use Data to Provide Specific, Actionable Feedback The most . Data can help you focus your conversations on certain aspects of a developer’s workflow, or specific units of work, so you can more effectively coach each individual developer. effective feedback is specific and actionable For example, let’s say one of the developers on your team is consistently opening large Pull Requests. You could simply encourage them to “open smaller Pull Requests,” but that feedback might not be effective if they’re having trouble finding ways to break down their work. Instead, it can be helpful to identify some of their largest Pull Requests and bring them to your evaluation. That way, you can take a look at some actual Pull Requests together and discuss ways they could be broken down into smaller parts. With concrete examples and a bit of focused coaching, that developer will walk away from your conversation with actionable strategies for opening smaller Pull Requests, and you’ll be more likely to see them achieve the desired result. In cases where your team members are seriously underperforming to the point where their job really is at risk, it can be helpful to set clear, specific performance expectations. With easy-to-understand targets, that team member may have an easier time doing what they need to do to stay afloat. Think Beyond the Annual Review Even if you’re able to run objective, compassionate performance reviews that leave your team members with actionable feedback, It’s not always easy for a team member to speak up and ask for support, and it’s difficult for developers to keep growing when they’re only getting feedback once a year. annual performance reviews happen too infrequently to maximize their potential for positive impact. If you don’t use them already, consider making regular 1-on-1s part of your management repertoire. With frequent 1-on-1s, you’ll , and with more frequent check-ins, you’ll be able to more effectively support them through difficult situations, whether it’s a personal challenge, like a sick loved one, or a professional one, like a communication breakdown with a fellow team member. get to know your team members on a more personal level Re-Evaluate Your Evaluation Process If there was ever a year to re-evaluate the way you handle performance evaluations, this is it. While current circumstances may have generated extra pressure to meet business numbers, they have also created extra reason to be compassionate. As a leader, it’s your responsibility to ensure that business pressure doesn’t compromise your team member’s well-being, and to create the best possible circumstances for your team member to do their job. No matter what you do, some of your team members may be struggling due to circumstances completely beyond either of your control. It may not be the right time for them to boost their productivity or reach the next level of professional success, and that’s ok. Previously published at https://codeclimate.com/blog/performance-reviews/

How to Reshape Performance Reviews for a Difficult Year and Beyond

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

Managers: Beware the Fallacy of Process

Preparing for a board meeting is a stressful experience for everyone. For many CTOs, it’s also an exercise in futility, trying to zero in on engineering KPIs that accurately represent everything that’s happened in the department. The information that usually makes it to the board deck — information on completed features and incident reports — doesn’t tell the whole story. A list of features shows what the team accomplished, but doesn’t reveal anything about how the team works. It can’t reveal process issues that need to be addressed or highlight challenges the team has overcome. Similarly, incident reports might illuminate problems in the codebase, but they’re devoid of context about how the team is dealing with those issues. Other departments have self-evident, objective KPIs. Sales, for example, can walk through their pipeline from demos booked to contracts signed, using objective measurements to chart their department’s progress over time. Engineering leaders, on the other hand, must get creative to provide that level of clarity. You’ll need to think carefully about the story you want your slides to tell, then choose engineering KPIs that map to those specific insights. When considering a metric, we recommend asking: Will this demonstrate the department’s success (or lack thereof)? Does this highlight something interesting or unexpected, and start a conversation? Will this help me ask for advice from the board? These parameters will help you select the right data to drive productive conversations, so you can walk away with actionable guidance from the board. Start with Engineering Success Metrics To convey big-picture information, start your presentation with engineering success metrics. Success metrics speak to outcomes; they measure the results your team is getting. In engineering, there are two aspects of success: planning and execution. Engineering decks usually include feature lists, which speak to your team’s ability to plan. But most engineering decks stop there. To dig into execution — your team’s ability to consistently ship projects — you’ll need another set of success metrics. When choosing success metrics that highlight execution, look for metrics based on objective data rather than subjective measurements like story points. With objective data, you’ll be able to track progress across teams, projects, and quarters, and for your department. Use metrics like: set more effective goals - A count of the engineering team’s deploys within a given period of time, Deploy Volume can help quantify the engineering team’s capacity. Deploy Volume - The number of Pull Requests merged over a period of time. Similar to Deploy Volume, PR Throughput can help you quantify how much the engineering team is getting done. PR Throughput - The time between the first commit logged in a Pull Request, and when that Pull Request is merged. Cycle Time acts as a proxy for engineering speed and can help you communicate how quickly the team is moving. Cycle Time Drill Down with Revealing Engineering KPIs After you report on success metrics, you’ll want to dive into additional metrics that provide critical context and perspective. Think about what you know to be true for your team, and then pick the data that will help you illustrate that to the board. You might want to include information that reveals the impact of a key decision or highlight a specific data point that raises an important question for discussion. Be open to all kinds of data — both quantitative and qualitative — and consider pairing multiple metrics to add dimension, or to answer questions before they arise. To determine which additional metrics might be useful, ask yourself: What did we promise the board at our last meeting, and how can we represent whether we made good on that promise? What took up a lot of engineering time this quarter? For example, were you making a big security push, focused on new features, or working through technical debt? What big changes or strategic decisions did we make this quarter? For example, did you increase headcount, initiate a re-org, or change an aspect of your review process? Your answers will be different every quarter, and they won’t always be noteworthy enough for the board. But your line of questioning might also uncover something that is important to share and not already covered in the deck. For example, let’s say at last quarter’s board meeting, you discussed implementing a support engineering rotation. This quarter, you might want to show the board that it’s having a positive impact on the team’s ability to resolve customer issues. To do that, you could report on the Issue Cycle Time of Escalations, which measures how long it takes for an escalation to be addressed once it’s opened. Though highly specific, this software development metric would demonstrate the success of the support initiative. Put Engineering Metrics in Conversation Putting metrics in conversation with each other can also help paint a more complete picture of what’s happening on your team. For example, it might be useful to share the engineering department’s PR Throughput, coupled with incident data. Either one of these metrics would be useful in isolation, but taken alone, a high PR Throughput might raise the implicit question: is the engineering team sacrificing quality in order to keep deployment high? By pairing PR Throughput with incident data, you’d be able to demonstrate that the team isn’t solely focused on deployments, they’re also consistently delivering quality code. You might also consider pairing metrics to demonstrate the impact of a strategic decision. Let’s say you recently hired three new engineers. You might want to share PR Throughput, paired with Active Contributors, to illustrate the team’s increasing output as the newly onboarded engineers begin to contribute more and more to the codebase. Most board meetings include a lot of anecdotal evidence from the engineering department. The inclusion of objective metrics can help you show the board exactly what’s happening on your team, so they can participate in the conversation more effectively, and offer up more useful guidance. Make Board Meetings Work for You The goal of a board meeting is to provide vital context so that the board can do what it’s there to do — offer advice and help with key strategic decisions. Subjective metrics and flawed measurements might feel like relevant updates, but they won’t reveal enough actionable information about what’s going on in your department. Think about what you want to get out of the board meeting, and then choose the data that provides essential context for those conversations. Previously published at https://codeclimate.com/blog/engineering-kpis-board-deck/

The Most Important Enginnering KPIs for Your Board Deck

When your team is building a software product, the majority of the work that they do is invisible. As a manager, you have to rely on in-person cues for blocked work or frustrated engineers. When they move to a remote workflow—your team also becomes invisible, and all those critical signals are dropped. In-person, you might notice: Nonverbal clues during stand-ups or retros Frequent interruptions as developers are pulled into meeting after meeting Tension between team members as they work through problems Acting on these signals is one of the most important ways you can help your team. You might say: “I noticed you seem frustrated each time you worked with Jack—is everything okay?” Or “I noticed that you’ve been helping the marketing team a lot, do you have too much on your plate right now?” When you transition to a remote workflow, you lose indicators that anyone is stuck, demotivated, or overworked. To adjust, you have to find new ways to broaden the now-limited purview that remote work allows. Signals to Remain Context-Aware From Afar When thinking about productivity or output, many software leaders think in terms of features or story points. They get a general sense of how things are moving (or not moving) based on whether these features are getting completed. But these metrics are lagging indicators, and they’re not diagnostic. If you know that you’ve shipped fewer features one sprint than you did in the previous, you have no insight into what you can do to improve things. Fortunately, we can derive much more granular signals for the speed and effectiveness of software development from the systems in which engineers already work. Data from how a developer works in their version control system, such as Commit Volume, Code Churn, or Pull Request Cycle Time, better clues you into how your team is working in real-time. These metrics are imperfect (as all metrics are), but they give you much more to work with in terms of diagnosing process problems within your newly-distributed workflow. Below, we’ve recommended a set of metrics that you can look at on a daily, weekly, and monthly basis to stay connected with how your team is working. Daily Signals for Stuck Work The most imminent threat to an efficient and happy remote team is stuck work. An engineer might be stuck because they are unsure of how to implement a change, because they’re unfamiliar with a portion of the codebase or for a number of other reasons. Any unit of work that isn’t moving through the Software Delivery Process quickly enough is a signal for you to check in. Look out for: Are team members working incrementally? Are they working on a particularly tough portion of the codebase? Infrequent pushes: Are team members reworking the same lines of code over and over again? Is there clear communication surrounding feature implementation? Rework: Are there Pull Requests that have been open for more than three business days? Is this causing multi-tasking? Long-running Pull Requests: Is a single Pull Request taking up the attention of several engineers who may be in disagreement? Pull Requests with 3+ participants: Are there Pull Requests that have been passed back and forth between the reviewer and the author several times? Pull Requests stuck in code review: shows all work in progress. See at-a-glance the Pull Requests that are most likely to impede your team. If you look at these signals with your team, you’ll have a shared understanding of how things are moving and where someone might be stuck. This data will take the pressure off developers to raise their hand during when something’s off track, and enable you, as a manager, to know when you can step in and help. Velocity daily stand-ups Weekly Signals for Goal Setting Once you’ve started tracking daily signals to keep your team on track, you can take a step back and start looking at how your engineers are working. If individual engineers are spending days working through a problem on their individual device, then opening huge Pull Requests that are perpetually getting stuck in the review process, your team will constantly feel stuck and frustrated. Agile and Continuous Delivery workflows demand that team members commit frequently, work in small batches, and limit work in progress. These habits set in motion what we call the : Virtuous Circle of Software Delivery Building these habits is crucial to minimize the risk associated with merging a PR and decrease the chances that an individual unit of work will get stuck in the process. For this, we recommend working with team members to set up process SLAs for good collaborative practices every week. Then, during retros and 1:1s, developers can work through concrete examples of when something went off track. You can set targets for things like: Can we agree that 95% of PRs should be successfully merged? We’ll investigate PRs that were closed or abandoned. Pull Request Success Rate: Can we agree to get to code reviews within 8 hours for 80% of Pull Requests? We’ll look deeper into PRs that couldn’t be reviewed quickly. Pull Request Time to Review: Can we agree to keep Review Cycles under 2 for 95% of Pull Requests? We’ll look into any PRs that get passed back and forth between author and reviewer multiple times. Pull Requests Review Cycles: Can we agree that 70% of the work should be done by at least 50% of the team? We’ll investigate deeper if just a few individuals seem to be doing most of the work. Workload Balance: Velocity’s Target feature lets you set SLAs to help hold your team accountable to their goals. Naturally, you don’t need to look at all of these metrics right away—just pick one or two that represent commonly reported issues. Selecting a granular metric, like Workload Balance, will be a much more effective indicator of what’s going amiss than a metric like Features Completed. Over time, your team can build habits that minimizes the opportunity for work to get stuck and slow down the team. Monthly Signals for Continuous Improvement Once you've identified signals that can point you towards daily and weekly improvement opportunities, you’ll want to start looking at your processes end-to-end to ensure that they’re working for, not against, your team members. First, you’ll want to make sure your processes work. If you’re working in a traditional Git workflow, you’ll want to make sure that PRs are moving along the “happy path” from Open to Reviewed to Approved to Merged. Any PRs that skip steps are working outside your process and represent opportunities for deeper investigation. Next, you’ll want to see how well this process is enabling a low time-to-market. If it takes days or weeks for changes to get into the hands of customers, your team will have a hard time quickly mitigating issues in production, and, ultimately, keeping up innovation. For this, you’ll want to keep an eye on your team’s delivery Cycle Time, or how long, on average, it takes PRs to go from a developer’s laptop to being merged to production. Velocity lets you visualize the journey of your Pull Requests from open to merged. Below, you can see metrics that represent constituents of this journey to better diagnose slowdowns. A that’s short and consistent is an indicator that your team is working with little friction, and your processes are enabling rapid innovation. If your Cycle Time is spikey, you’ll know to look into the units of work that make up a particularly high week. If your Cycle Time seems consistently high, you’ll want to to see, specifically, which processes or practices are dragging down your speed. We recommend looking at: Cycle Time break it up into components How much time passes between the earliest commit and the opening of a Pull Request? Time to Open: How much time passes between when a PR is opened and when it is first reviewed? Time to First Review: How much time passes between when a PR is opened and when it is merged to production? Time to Merge: Comparing these side by side will help you see where in your process your developers are being slowed down. When your team moves the needle and improves Cycle Time, it means you’re working together to boost the efficiency of the development process and to accelerate innovation. It’s important to communicate and celebrate success surrounding this metric to encourage continuous improvement on your team. Remote Engineers Deserve Great Leaders An unexpected transition to remote work is one of the most trying experiences for many software engineers. The already-isolating job of writing code becomes even harder when team members can’t chat or take breaks together. Leadership that is disconnected or not aware of all the challenges that they’re facing can be the final nudge that can disengage a team member. Fold in just a few extra signals to stay aligned with engineers and lend a hand when they need it most. We’ve worked with many organizations to help them smooth the transition from on-site to remote workflows. During this particularly difficult time, we’re giving away our analytics product, along with data coaching and support, for free for 45 days . Previously published at https://codeclimate.com/blog/the-essential-data-for-leading-a-remote-engineering-team/

The Essential Data for Leading a Remote Engineering Team

“Effective engineering leadership is being outcome-oriented,” says Kickstarter’s Mark Wunsch. When Mark first joined Kickstarter as VP of Engineering, one of his first decisions was to re-organize the engineering department, based on business-oriented objectives. Each 3–7 person scrum team focused on a different “essence,” or a different customer-facing part of the product. This helped engineering understand their work from a business perspective. Mark tells us, “The objective is not to ask, ‘Is the code good?’ but to ask ‘Is Kickstarter good?’” The engineers’ perspective, however, was difficult to communicate with leadership. The engineers were constantly bogged down by problems that were invisible to non-technical colleagues, such as legacy code. Kickstarter has been around for about 10 years, so a big portion of the codebase was troublesome to work with. Mark told us, “To an engineer, it’s so obvious when a piece of code is brittle, but it’s really hard to advocate for putting engineering resources into solving technical debt.” Mark decided to use metrics to further align engineering and leadership. Diagnosing technical debt with data Every developer knows that legacy code undoubtedly slows down engineering. But taking weeks away from shipping new features compromises how much new value the company is delivering to customers. Before making a case for refactoring to leadership, Mark decided to do a deep dive into where technical debt was slowing down the team. He used engineering analytics tool to learn how each engineering team was working and where they might be getting stuck**.** Velocity Mark started by looking at his team’s weekly throughput, as measured by merged pull requests. Whenever the throughput dipped significantly below their average, he’d know to investigate further. Seeing a low Pull Requests/Merged at the end of the week can be a red flag a team was stuck. Unlike subjective measures that are common on most engineering teams, like story points completed, Velocity metrics are represented by a concrete unit of work: the Pull Request. This enables Mark to objectively understand when a scrum team is really bogged down, compared to the last sprint or last month. Once he spotted productivity anomalies, Mark would pull up a real-time report of his teams’ riskiest Pull Requests. Pull Requests that were open longer and had a lot of activity (comments and back-and-forths between author and reviewer) were at the top of the list. An example of Velocity ’s Work In Progress which shows the old and active pull requests that may be holding up the team. Because trickier parts of the applications tend to require more substantial changes, pull requests that are most “active” often point Mark to the most troublesome areas of the codebase. After a few weeks of investigation, Mark was able to find concrete evidence for what his intuition was telling him. “The data showed that we were consistently slowed down because of legacy code,” said Mark. Bringing transparency to engineering practices During meetings with the executive team, Mark could now point to weeks with less output and prove that technical debt was impeding the engineering team from their primary business objective: continuously delivering new features. To communicate how the team was doing, he’d present a Pull Request throughput chart with a trend line: A Velocity report showing Pull Requests Merged/Day, over the last 3 months. This helped leadership visualize how much Kickstarter was growing in their engineering efficiency but also opportunities for further improvement. Mark also shared Cycle Time (i.e., how quickly code goes from a developer’s laptop to being merged into master.) A Velocity report that shows the fluctuation of Cycle time, over the last 3 months. Cycle time was a great indicator for how much trouble it was to make a change to the codebase. High cycle time would often correspond to low output a day or two later, showing that some form of obstruction existed for a developer or team. These two charts, along with Mark’s summary of his more technical findings, aligned all of leadership around scaling back on new features temporarily and dedicate more time to refactoring. Bridging engineering and leadership After spending time investigating what legacy code was slowing down the team, Mark was able to take a strategic approach to how they tackled technical debt. Rather than jump on the opportunity to fix anything that looked broken, he could have teams focus on the biggest productivity blockers first. Engineers were happy because they had the time to rework the legacy code that was constantly slowing them down. Leadership was happy when they could see long-term improvements in engineering speed. Six months after refactoring, Kickstarter saw a 17% increase in Pull Requests merged and a 63% decrease in Cycle Time. It was a win-win-win. Mark tells us, “Being able to talk about technical debt in the same way we talk about business metrics is incredibly powerful.” If you want to , . learn exactly how much technical debt is slowing down your own engineering team try Velocity free for 14 days Originally published on codeclimate.com

How Kickstarter’s Mark Wunsch Used Engineering Metrics to Make a Case for Refactoring

Thousands of happy customers validated our software– but dogfooding validated our values. Velocity A couple of years ago, our engineering leaders were anecdote-driven, like just about everyone else in the industry. We knew how much progress an engineer had made on a new feature because we asked. We knew why we missed a deadline for launching a new feature because we discussed it in our retros. But we couldn’t answer simple questions like: Is our efficiency increasing or decreasing over time? What work slows us down and where is the biggest opportunity to improve? Which developers on my team are stuck, right now? Even on a small development team, the insights that we had into our own productivity were limited. Last year, we launched Velocity, an designed to help teams big and small with exactly the issue that we, ourselves, experienced. In the process of iterating and improving the platform, our Engineering Manager, Ale Paredes dogfooded our app. She used each feature from Velocity as soon as it was built and has experienced the benefits of data-driven engineering first-hand. engineering analytics tool Armed with Velocity, she addressed burnout, improved remote collaboration, and helped restructure the engineering team. The result was an 83% increase in productivity, and a healthier, more engaged dev team. Here’s what dogfooding has done for Code Climate. Velocity We Ditched Flat and Near Doubled Our Efficiency Flat structure doesn’t scale. There comes a point along every engineering team’s growth where the same set up that once built camaraderie and a shared purpose now fuels disengagement and a lack of focus. Ale first started noticing that disengagement during daily standups. Some people were zoning out; others were on their phones. Almost no discussion was happening. It was 20 minutes of engineers taking turns speaking, one by one. When she brought this up in her 1:1s that week, she found that the team was in unanimous agreement: meetings were inefficient and taking up too much time. Ale checked her hypothesis against the metrics by looking at Pushes per Day over the last 6 months. A custom report Ale built to see how Pushes per Day has been affected as the team scaled. Velocity Velocity gave her confirmation that the team’s efficiency had, in fact, been steadily decreasing over the past four months. Ale took this insight back to the leadership team, and together, they decided it was time to ditch flat. Software development is inherently collaborative, and if engineers have too many co-workers to support, they can’t feel invested in one another’s work. We decided to break up the ten-person team into groups of three or four engineers. We hypothesized that breaking up teams by would help individual engineers focus on less tracks of work. As a result, meetings would suck up less time and be more engaging, as smaller teams only hash out problems relevant to the few people involved. Bezo’s 2-pizza rule When Ale implemented this change, the feedback was overwhelmingly positive. Engineers were doing more of what they liked (coding), and less of what they hated (meetings). Over the course of several months, the metrics corroborated what the team was feeling: we started moving much faster. A custom report Ale built to see how Pushes per Day has increased since the re-org. Velocity We went from an average of in November to an average of in January, an 83% increase. 12 pushes/day 21 pushes/day We Coached Remote Team Members for Better Collaboration Agile software development relies on strong communication, and, in many cases, frequent face time, so managing team members that are an ocean and three time zones away is nontrivial. It’s hard to perceive frustration through Slack. It’s hard to understand workload through Zoom. Ale made a concerted effort to check in with remote team members and find out what’s going well and where they might be in need of coaching. But not everyone is an open book– many of her remote team members hesitated to bring up troublesome pull requests or bottlenecks during these meetings. To find a starting point for these conversations, Ale started looking through a handful of contributor metrics on a weekly basis. She would pay particular attention to overall throughput (# of PRs merged), rework (how often developers work on their own recently merged code), and cycle time (how long it takes code to go from a developer’s laptop to being a merged PR). By putting together a chart in Velocity, she started noticing a pattern. Remote developers had a significantly higher cycle time than HQ team members. A custom report Ale built to see Median Cycle Time by team member. Velocity Before a 1:1 with Legolas Greenleaf, Ale dug deeper into Velocity to see where, exactly, in the PR process contributors were getting stuck. A chart that shows how contributors are performing on metrics compared to the industry standard. Velocity Ale discovered that Legolas was spending a lot of his time working on code on his laptop before opening up a Pull Request and getting his work looked over. The next time they sat down, Ale discussed the trend she noticed. The remote team member was able to speak more specifically about what has been slowing him down and what challenges he was facing. In their conversation, she guided Legolas towards learning how he could’ve better approached some of the last few PRs. Together, they discovered the heart of the problem was that his PRs were too big. Splitting up projects into smaller pieces was a work habit that the HQ team had heard a ton, but the distance between Ale and the remote workers meant they weren’t aligned in terms of best practices. The data brought Ale’s attention to the problem, and gave her something objective to work off for her coaching sessions. We Prevented Burnout in our Engineers Meeting deadlines and building great products isn’t the only measure of a good team. We also want engineers to be engaged and not overworked so that our pace is sustainable. Too often, however, burnout is impossible to sniff out until it’s too late. Last December, the team was on a tear. We were shipping features every other day, we had redesigned most of the pages in the application, and everyone was stoked about all the cool new stuff we were building. Everything seemed great. During her weekly check-ins, however, Ale started noticing a trend. Engineers were excited about their work, but everyone seemed to be feeling a lot of pressure to get features shipped– even though we were ahead of schedule. One senior engineer mentioned that he barely had time for code reviews. Other team members started neglecting pair programming in favor of spending more time getting stuff out the door. Ale used Velocity to take a look at what the team had on their plate: ’s Activity Log showed leadership how much individuals were working. Velocity She noticed that some developers had so much activity, it barely fit in their row. In a few cases, we were even pushing on weekends, which is highly unusual for our organization. Looking through all the PRs and reviews the engineering team was churning out, Ale became suspicious that people were working overtime. She put together a report using Velocity’s Reports Builder to see how many pushes were made after 8pm each week: Ale built a custom Velocity report to see who was working late hours. During the last two weeks, the team had been working late hours more than they had in the previous three months combined. Ale brought this data to the leadership team and was able to successfully advocate scaling back work and giving the engineering team a well-deserved day off. Now, Ale checks these dashboards regularly and sends out a monthly survey to check in on how work is distributed and how team members are feeling. Measure and Mobilize Metrics are not everything. Metrics didn’t help Ale notice that engineers were disengaged during meetings, or that remote team members weren’t voicing problems. Instead, metrics helped her check her intuition with more transparency into what’s going on. They also enabled Ale to verify that the changes she made generated an improvement in our productivity. This gut-check was invaluable in helping us move faster and communicate better, both inside the engineering team and with the organization as a whole. If you want to learn more on how Velocity can let you see deeper into your team’s work habits (and help you move at least 20% faster), sign up for a demo . here Originally published at codeclimate.com .

How We Increased Productivity 83%, Improved Remote Collaboration, and Prevented Burnout by…

260 Stories To Learn About Team Productivity

183 Stories To Learn About Engineering

In 2022, Gartner named Microsoft Power BI the Business Intelligence and Analytics Platforms leader. With the aid of business intelligence tools like Microsoft Power BI, unstructured data can go through extraction, cleaning, and analysis processes to create insights that help organizations make data-driven decisions. In this article, we will look at the , which are essential in helping data professionals build their proficiency in Power BI. 13 Best Datasets for Power BI Practice List of the Best Datasets for Power BI Practice 1. Sample Superstore Sales The Sample Superstore Sales dataset provides sales data for a fictional retail company, including information on products, orders and customers. This dataset includes the following variables: Order ID - A unique identifier for each order. Customer ID - A unique identifier for each customer. Order Date - The date of the order placement. Ship Date - The date the order was shipped. Ship Mode - The shipping mode for the order (e.g. standard, same-day). Segment - The customer segment (e.g. Consumer, Corporate, Home Office). Region - The region where the customer is located (e.g. West, Central, East). Category - The category of the product purchased (e.g. Furniture, Technology, Office Supplies). Sub-Category - The sub-category of the product purchased (e.g. Chairs, Desktops, Paper). Product Name - The name of the product purchased. Sales - The sales revenue for the product purchased. Quantity - The number of units of the product purchased. Discount - The discount applied to the product purchased. Profit -The profit generated by the product purchased. 2. Adventure Works DW The Adventure Works DW is a sample database for Microsoft SQL Server Analysis Services (SSAS). It offers a dimensional data model for a fictional bicycle manufacturer, Adventure Works Cycles. It also comprises information on product catalogues, sales, customer demographics and time-based data for analysis & reporting. This dataset includes the following variables: Customer -This includes customer demographics, such as age, gender, education, and income. Sales - This includes sales information, such as sales territory, salesperson, and order date. Product - This includes product categories, subcategories, and product names. Date -This includes the date and related attributes such as quarter, month, day, and day of the week. Geography - This includes customers' state, city, postal code and sales orders. To download this dataset, you can click . here 3. Flight Delays and Cancellations This real-world dataset comprises data on flight numbers, departure, airlines, arrival times and the reason for any delays or cancellations. With this dataset, Power BI users perform data analysis and create interactive dashboards to identify the most common causes of flight disruptions by studying the frequency of cancellations by airline and flight delays. It comprises the following variables: Flight Duration - The length of time from departure to arrival for the flight. Delay Reason - The reason for any delay in the flight. Examples may include weather, mechanical issues, or air traffic control. Delay Time - The amount of time by which the flight was delayed. Cancellation Reason - The reason for cancellation of the flight.  Examples may include weather, mechanical issues, or insufficient passenger demand. Date of Flight - The date on which the flight took place. Flight Number - A unique identifier assigned to each flight by the airline. Airline Name - The name of the airline operating the flight. Departure Airport - The airport from which the flight is scheduled to depart. Arrival Airport - The airport at which the flight is scheduled to arrive. Scheduled Departure Time - The time at which the flight was scheduled to depart, as originally planned by the airline. Actual Departure Time - The actual time at which the flight departed, if different from the scheduled departure time. Scheduled Arrival Time - The time at which the flight was scheduled to arrive, as initially planned by the airline. Actual Arrival Time - The actual time at which the flight arrived, if different from the scheduled arrival time. 4. NYC Taxi Data NYC Taxi Data is a rich and complex dataset that contains info on taxi trips in New York City, including trip durations, fare amounts, and pickup and drop-off locations. It covers millions of trips and spans several years, providing a rich source of information about urban mobility and transportation patterns in the city. By analyzing this data, you can gain insights into various areas of the taxi industry in NYC. For example, you can visualize the distribution of trips over time and space, and identify hot spots of taxi activity in the city. The dataset includes the following variables: Trip Duration - The duration of the trip, in seconds. Trip Distance - The distance travelled by taxi, in miles. Number of Passengers - Total number of passengers in the taxi. Fare Amount - The fare charged to the passenger, in dollars. Payment Method - The method of payment used by passengers (e.g credit card, cash etc.). Pickup and Drop-off Location - The GPS coordinates of the pickup and drop-off locations. Trip Type - This indicates whether the trip is a dispatched trip (green taxi or for-hire) or a street hail (yellow taxi). Pickup and Drop-off Time - The time and date at which the pickup and drop-off took place. To download this dataset, click . here 5. Global Superstore The Global Superstore dataset is a simulation of retail sales operations with stores in multiple countries. It includes information about customers, orders and products, which is particularly useful for exploring retail sales data, as it offers a large and diverse set of data that can be used to analyze customer behaviour, product performance and sales patterns. It comprises the following variables: Order ID - A unique identifier for each order. Order Date - The date and time the order was placed. Ship Date - The date and time the order was shipped. Ship Mode - The method used to ship the order (e.g. standard, express). Customer ID - A unique identifier for each customer. Customer Name - The full name of the customer. Segment - The customer segment such as Home Office or Corporate. Country - The country where the customer resides. City - The city where the customer resides. State - The state where the customer resides. Postal Code - The postal code of the customer's residence. Region - The geographic region where the customer resides. Product ID - A unique identifier for each product. Category - The broad product category, such as Furniture, Office Supplies, or Technology. Sub-Category - The specific product sub-category, such as Chairs, Paper, or Phones. Product Name - The name of the product. Sales - The total sales revenue for the product. Quantity - The number of units of the product sold. Discount - The discount applied to the product. Profit - The total profit earned from the product. To download this dataset, click . here 6. Seattle Weather Data This dataset is a comprehensive dataset which provides historical weather information for the Seattle, Washington area. It can be used to study the climate and weather patterns as well as weather’s impact on various industries and activities, such as tourism, agriculture and transportation. Some of the critical variables in the Seattle Weather Data include: Date - The date of the observation. Prcp - The amount of precipitation, in inches. Tmax - The maximum temperature for that day, in degrees Fahrenheit. Tmin - The minimum temperature for that day, in degrees Fahrenheit. Rain - This shows TRUE if rain was observed on that day and FALSE if it was not. 7. World Bank Development Indicators This dataset contains information on GDP, life expectancy, and literacy rates for various nations throughout the world. It also includes many economic and social variables. Some of the variables included in this dataset are: Gross Domestic Product (GDP) Inflation Unemployment rate Government debt Trade balance Life expectancy Infant mortality rate Access to electricity Literacy rate Mobile cellular subscriptions Note: The variables included in the dataset depend on the year and the country being analyzed. You can download the dataset directly from the or you can download it on . website Kaggle 8. US Health Data The US Health Dataset provides comprehensive information on health behaviour and health status, including data on healthcare utilization, physical activity and chronic diseases. It can be used to study trends in public health and to investigate the impact of lifestyle and health behaviour on health outcomes. The US Health Data is sourced from the Centers for Disease Control and Prevention (CDC), the National Center for Health Statistics (NCHS), and the Agency for Healthcare Research and Quality (AHRQ). The common variables in this dataset include: Demographic information -  Age, gender, race, and ethnicity Health status indicators - Self-reported health, chronic conditions, and disability Healthcare utilization measures - Hospitalizations, emergency room visits, and primary care visits Health behaviours - Smoking, exercise, and diet Health outcomes - Life expectancy, mortality rates, and incidence of specific diseases Healthcare costs - Total medical expenditures, out-of-pocket costs, and insurance coverage Access to healthcare, including insurance coverage, availability of healthcare providers, and proximity to healthcare facilities Note: Variables included in the US Health Dataset can vary depending on the data source. 9. Stack Overflow Survey Results Stack Overflow Survey Results contain results from the annual Stack Overflow developer survey. It includes various aspects of developer experience, such as salary and compensation, preferred technologies, work satisfaction etc. It can be used to explore and gain insights into the state of the developer community. This dataset contains a large number of variables, including but not limited to the following: Personal Information - Age, gender, country, and education level. Employment - Employment of employment, company size, and job title. Development Experience - Years of experience, primary programming language, and development environment. Salary and Compensation - Salary, currency, and benefits. Work Satisfaction - Job satisfaction, career satisfaction, and job search. Technology Usage - Preferred operating system, programming language, development environment, and tooling. Community Involvement - Contributions to open-source projects, Stack Overflow reputation, and participation in developer communities. The dataset can be downloaded directly from the . website 10. Titanic: Machine Learning from Disaster This popular open-source dataset offers information on the passengers onboard the Titanic ship when it sank on April 15, 1912. Some of the variables included in the dataset: PassengerId - A unique identifier for each passenger. Survived: This shows whether the passenger survived or not (0 = No, 1 = Yes). Pclass: A passenger's class (1 = 1st, 2 = 2nd, 3 = 3rd). Name - A passenger's name. Sex - A passenger's gender. Age - A passenger's age. SibSp - The number of siblings/spouses aboard. Parch - The number of parents/children aboard. Ticket - The ticket number. Fare - The fare paid for the ticket. Cabin - The cabin number. Embarked - The port of embarkation (C = Cherbourg, Q = Queenstown, S = Southampton). You can download the dataset on . Kaggle 11. Wine Quality The Wine Quality dataset contains information on red and white wine samples. The goal of this Power BI dataset is to classify the quality of the wine based on chemical properties like pH, density, alcohol content and citric acid content. The common variables included in this dataset: Fixed Acidity - The number of fixed acids in the wine, expressed in g/dm^3. Volatile Acidity - The number of volatile acids in the wine, expressed in g/dm^3. Citric Acid - The amount of citric acid in the wine, expressed in g/dm^3. Residual Sugar: The amount of residual sugar in the wine, expressed in g/dm^3 Chlorides - The amount of chloride in the wine, expressed in g/dm^3. Free Sulfur Dioxide - The amount of free sulfur dioxide in the wine, expressed in mg/dm^3. Total Sulfur Dioxide - The amount of total sulfur dioxide in the wine, expressed in mg/dm^3. Density - The density of the wine, expressed in g/cm^3. pH - The pH level of the wine. Sulphates - The number of sulphates in the wine, expressed in g/dm^3. Alcohol - The alcohol content of the wine, expressed in % vol. Quality - The quality rating of the wine, on a scale of 0 to 10. You can download the dataset from by clicking . UCI Machine Learning Repository here 12. US Crime Rates The US Crime Rates dataset provides information on crime rates in the United States. It is organized based on geographical region, period or other relevant factors and is mostly used to analyze crime trends and patterns or as well to support criminal justice decision-making and law enforcement. It is also commonly used for exploratory data analysis and visualization and can be used to create interactive dashboards and reports in Power BI. Some of the variables included in the dataset: M - The percentage of males aged 14–24. Po1 - The per capita expenditure on police protection in 1960. Po2 - The per capita expenditure on police protection in 1959. M.F - The number of males per 100 females. You can download the dataset from . Kaggle 13. Airbnb Listings This dataset is a collection of data on Airbnb listings, including price, amenities, type of property, number of bedrooms and location in New York City. It is commonly used for exploratory data analysis and visualization, with a focus on the distribution of listings and prices across different locations and neighbourhoods. Some of the variables included in the dataset: Id - Airbnb's unique identifier for the listing. Host Id -  Airbnb's unique identifier for the host. Host name - The name of the listing. Neighbourhood Group - The neighbourhood group e.g Manhattan, Brooklyn etc. Host identity verification - This shows if the host identity is either verified or unconfirmed. The dataset can be accessed on Kaggle by clicking . here Common Project Use Cases for the Power BI Datasets Retail Analytics Sample Superstore Sales Global Superstore Adventure Works DW Retail sales analysis, customer segmentation, product performance analysis, market segmentation and sales territory analysis. Transportation Analytics NYC Taxi Data Flight Delays and Cancellations Taxi demand and supply analysis, trip analysis, driver performance analysis, fare comparison, flight performance analysis and airport comparison. Weather Analytics Seattle Weather Data Weather trend analysis, climate change analysis, prediction of weather patterns and impact on various industries. Economic Analytics World Bank Development Indicators Global development analysis, comparison of countries, prediction of economic trends and economic performance analysis. Healthcare Analytics US Health Data Healthcare analytics, comparison of states, analysis of healthcare spending and outcome. Workforce Analytics Stack Overflow Survey Results Workforce analysis, technology trend analysis, comparison of salary and job satisfaction. Machine Learning/Survival Prediction Titanic: Machine Learning from Disaster Survival prediction, data analysis and visualizations of the Titanic disaster. Quality Analysis Wine Quality Quality analysis, prediction of wine quality based on its chemical properties, wine preference analysis and recommendations. Crime Analytics US Crime Rates Crime analysis, comparison of crime rates by city, state and region, and analysis of crime patterns and trends. Travel Analytics Airbnb Listings Travel analysis, housing demand analysis, rental pricing analysis and popular tourist destination analysis. Final Thoughts These datasets and common use cases will help you better understand the role of Power BI in helping organizations make smarter, real-time decisions. They are also available for anyone to download and use freely.

13 Best Datasets for Power BI Practice

It’s easy to using the built-in feature. One line in to rule them all: add test coverage on GitLab .gitlab-ci.yml test:
  coverage: /\d+.\d+ \% covered/ On the opposite side, GitHub doesn’t provide an option to add the test coverage badge. There are many third-party services for this purpose: , , , . It’s not a problem for an open-source project to use these services, cause they mostly provide a free tier for the open-source. codeclimate codecov codacy coveralls It hurts if you want to add the coverage badge to a private repository. All 3rd party options are paid. Samurai has two choices: Use a service to draw a badge based on provided JSON ( ); shields.io Generate a badge during CI/CD run and store it in the repository. Both options work. In the first case, you'll have to use an intermediate GitHub Gist, where you'll send the . Not an elegant approach. fresh coverage as a JSON file You must commit the SVG image to the repository in the second case. I've often seen recipes on the Internet where the badge was committed directly to the main branch. I think this is a bad practice: you'll clog up the history with garbage commits, which are useless by nature. There is a better choice. GitHub provides Pages service, where you can publish a coverage report for example. Technically, you can publish any static set of HTML files placed in a special branch. Looks like an ideal place for storing badges because it will not clog up the history of the main branch. gh-pages Take a look at the snippet with URLs below. If you are using a private repository, you will probably want to make the published report on GitHub Pages closed behind authorization as well. In that case, you won't be able to add a badge reference inside your README. Instead, provide a link to the RAW file in the repository. GitHub will redirect the request to something like . The parameter is generated for a closed repository for authorization purposes. The token is temporary — after several hours the link will become a 🎃. To avoid such behavior you may add a parameter to the file’s link: (1) (2) (3) token raw=true https://github.com/user/my-project/raw/gh-pages/badges/jacoco.svg?raw=true https://my-project.pages.github.io/badges/coverage.svg (1) GitHub Pages link
https://github.com/user/my-project/raw/gh-pages/badges/coverage.svg (2) RAW link
https://raw.githubusercontent.com/user/my-project/gh-pages/badges/coverage.svg?token=GHSAT0AAAAAABTVGF2OW2264AQOCSDOKKHGYXPQLUA (3) Permalink to the file in the private repo Let's put all the requirements together: You need to generate a badge using a command-line tool or a GitHub Action; It’s better to place the resulting badge in the branch; gh-pages In order to display the picture in the README even in a closed repository, you must use a direct link to the file with the parameter. raw=true Practice time! I forked repository. This is one of the implementations of the Conduit App (Medium.com clone). spring-boot-realworld-example-app We’ll use Action. jacoco-badge-generator Add a new step to the GitHub : Workflow config - name: Generate JaCoCo Badge
#      if: ${{ github.ref == 'refs/heads/master' }}
      uses: cicirello/jacoco-badge-generator@v2
      with:
        jacoco-csv-file: build/reports/jacoco/test/jacocoTestReport.csv
        badges-directory: build/reports/jacoco/test/html/badges We are specifying paths to JaCoCo CSV report and the resulting badge's directory. Uncomment the second line if you’d like to execute the step only in the main branch. The next step is to publish the report along with badges. I choose . github-pages-deploy-action - name: Publish coverage report to GitHub Pages
#      if: ${{ github.ref == 'refs/heads/master' }}
      uses: JamesIves/github-pages-deploy-action@v4
      with:
        folder: build/reports/jacoco/test/html We need to set the path to the HTML report. Just a reminder, the generated badge will also be inside this directory. After the commit you’ll need to open the repository and select the branch you want to publish the site from: Settings → Pages The last piece to add is the link to the badge in README. Don't forget about the parameter, so that the picture will be displayed for private repositories as well: raw=true [![Test Coverage](https://cdn.hackernoon.com/images/2hVuiN1gfbdO9OXUxjCttPNETq73-2022-08-08T22:19:48.257Z-cl6lbgrz6002p0as65v8sfgja)](https://drakulavich.github.io/spring-boot-realworld-example-app/) Hooray! All steps have been completed, you can . check the result By clicking on the badge you’ll open the coverage report: Please share in the comments your favorite GitHub Actions to prepare and publish the badges. Thank you for reading!

Adding Test Coverage Badge on GitHub Without Using Third-party Services

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

Learn how to start a tech startup with no money. You might think I am joking but I am not. In this no-fuss technical guide, I will walk you through the process to start a tech startup. This guide will not dive deep into the technical details. If you know technical things like how to set up a DNS, dockerize your applications, etc. you can glue together a tech startup for no cost at all. The for 12 months is key to getting your startup off the ground for around 9-10 months. Let’s get started: $300 free credit How to start a tech startup You have an idea for a tech startup in your mind for some time. You have fiddled around and maybe have a proof of concept or even a minimum viable product ( ) ready. Now it is time to get your startup out to the world. Or following the you want to see if there is a demand for your product. You also want to know if people are willing to pay for this type of service. MVP lean startup methodology For both the above cases, you will need a brand name and a working website or web application. This guide will help you get up and running at $0 stitching together the GCP products and other free services. Considerations You will need to register for a new GCP account and bag your that should be used by 12 months. $300 credit You will have to register for other services as you follow along with the guide. The aim is to run your staging and production applications for ~ $1 a day, so the $300 will last for just over 9.5 months. After that, you will need to find a way to generate money or get more Google Cloud Platform (GCP) credits like from or some way. Google for startups other For this guide, we will consider having a brochure JAMstack website hosted on Netlify. The web application will be hosted on Google Cloud Run with the MYSQL database on Google Cloud SQL. It is time to dive deeper into the steps: Steps Before we go deeper into the steps, these steps are going to be technical but not deeply technical. These steps are going to be more like pointers than a step-by-step process with screenshots in hyper details. If you have found the idea till now to be interesting carry on: Domain Name Your brand cannot exist without a domain name. This is where you might want to spend some money if you are more serious about your tech startup. Still, if you want to go the $0 path here is your option. You can register your domain at for $0. You can get domains ending with .ml, .tk, .ga, . FreeNom and .gq The good things are you pay $0 and there is no competition as getting a .com or .net. The flip side is you don’t get a “standard” domain as such. The choice is yours, if you are on a strict budget with $0 I would suggest to get a .ml domain and brand your startup as a “Machine Learning” idea, it has the potential to sell too :). DNS, security, and caching The next step after you register the domain is to get a free account. You can then use the DNS provided in your Cloud flare account at FreeNom to direct the website/web application traffic to where you want. In our case, we will like to redirect the brochure JAMStack to Netlify. The web application traffic will go our application hosted on Google Cloud Run. Cloudflare For now, be able to log in and “Add a site”. Then Google more about how to use cloud flare to linkup the traffic to respective services. On top of DNS management, you will also get things like caching and security for free with Cloud Flare. Again, I will leave you with more Googling to get all these configured correctly. You will also get free HTTPS with Cloudflare no need to wrangle with and settings. certificates The brochure site Now as you have your basics setup, it is time to get your brochure JAMStack website up and running. You can follow this step-by-step to get your JAMStack website running without a line of code. The main glue here is . With the recent changes, you could directly go to Stackbit, select a theme, and deploy your website on Netlify. You will also get an easy to use CMS with WYSIWYG type editor that works not only for text but for images, layout, and configuration of your website. tutorial Stackbit If your startup is a SAAS product I would recommend using the theme. It suits very well for SAAS products and with the click of a button, you can even change the color scheme. Azimuth Cement them together After you have your brochure website running on Netlify with Stackbit. Configure the DNS correctly on Freenom so that the website traffic hits the Netlify website with Cloudflare security enabled. You can scratch the surface to connect Freenom and Cloudflare with this . guide If you just want to test your idea then you can stop here. With the brochure website, you can start gathering email addresses using . Netlify forms free version has limits so please be aware of it, refer to the . After that, you can figure out if people will pay and should I actually write for the tech startup. Nelify forms Netlify Pricing page Take note that, for all the above services you have not even spent a penny. So you can run your experiment as long as you want. If you have already some code and some form of your tech startup working then proceed further to host it with GCP with serverless containers on Google Cloud Run. Time for Google Cloud Platform (GCP) Now is the time to get your Google Cloud Platform (GCP) account. This is where you will need to search for your credit card. Even though you will not be charged but Google will take in your credit card details. We will be using serverless containers for your application deployed on Google Cloud Run. We opt for serverless containers because of the and other reasons. The other mainly include no need to learn a new framework/paradigm and you can run any application as long as it can be containerized. You will also get free HTTPs and custom domain mapping to point the application back to the FreeNom domain. cost reasons With Cloud run you get 2 million requests a month . After that, it is 0.40 $ per million requests. Well, the math is not that simple but it is advertized like that for sure. Google cloud run is a lot easier to set up than a full-blown Kubernetes cluster with similar benefits. Know more about it in this . free talk Dockerize your application To deploy your application, you will need to dockerize it. In this you will see how to deploy a Laravel application to Google Cloud Run Fully managed. Following similar steps, you can deploy any PHP application to Google Cloud Run. Just bear in mind that you choose a lower-cost region like us-central-1 so that you don’t burn the free credit fast. step-by-step guide With my experience, currently, for an application with both staging and production workloads, it is costing us 10-20 cents a day. This is also going from our free credit. Database Just having some code doesn’t make the application work, the heard of most applications is the data. You can store your data on Google Cloud SQL over MySQL or Postgres SQL. This will be your main money hogger. With the current MySQL [pricing], using two instances it is costing us 88 cents a day. 44 cents per day for the staging database and the same for the production one. There is an automatic backup setup for the production one. db-f1-micro To save cost, if you can live with a maximum of 5 connections at a time you can choose to use . If you use remote MySQL for staging your daily cost for the database can come down to 44 cents a day. remote mysql One important thing is to keep your Cloud SQL instance behind a firewall. Follow the official to connect Cloud Run fully managed services with the Cloud SQL database. instructions If you use other forms of data storage the costs will vary depending on what you choose. Other GCP services In addition to Cloud Run and Cloud SQL, you should use other services to make your life easier. You can use Cloud Build to build your containers. It can be linked with Github and you can start building your containers on each push or with some conditions. Cloud build has per day free. It should be more than enough for a budding startup like yours. 120 mins With Cloud build the container images will be pushed to . Google Container registry uses to store the images. Set on the cloud storage bucket so that files older than X days can be auto-deleted before it mounts up the . Container Registry Cloud Storage lifecycle configuration cost You can also make use of the free VM - to do small tasks. We are using it to run a bot built with . It uses the gcloud command to do things like and display over Slack. So needless to say we are using and you should use it too. F1 micro instance Hubot deploy cloud run applications logs GCP logging Of course, GCP has a plethora of services but don’t get into the analysis paralysis mode and get nothing done. We used the above services and our product is running. Explore optimally and use the services needed for your product. Other free services The following are other free services that will help you build your tech startup: Github - Github has a so don’t forget to exploit it. With 2000 minutes for you can use it as your CI/CD pipeline too. free team plan Github Actions Trello / Asana - Depending on your project/product management flavor you can use or free version to manage your product development. Trello Asana CodeClimate - To keep a tab on the health of your code you can use CodeClimate with 4 seats. This will be a boon for your tech startup’s code quality. free plan ForwardEmail - Great you have your domain but using a Gmail email won’t work best for your brand identity. Get your for free with free plan. info@yourdomain.ml ForwardEmail Free CDN - If you are serving images or static assets on your website or web application you can use to get the CDN optimizations and benefits. Try it, it is free and unlimited too. Statically If you know of any other services that can help a budding tech startup please do add them to the comments section. Conclusion You don’t need money to get your tech startup off the ground. If you have the right idea and utilize your tech skills correctly you can get your tech startup started for $0. I hope you will not let your tech startup idea die and get something running for no cost with GCP and other services. Also published at: https://geshan.com.np/blog/2020/10/start-tech-startup/

Start a Tech Startup for Free with Google Cloud Platform

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

Stories, News & Mentions about CODECLIMATE

Codeclimate’s Stories on HackerNoon