Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Code churn is regarded by many software engineers as the best indicator of a code’s quality and defect density. Most engineers will also agree that code churn is good or bad relative to when and why it is taking place. As it’s relative, it can be confusing. It’s not a metric that you can look at and say, “Hey, I need to reduce my team’s code churn.” Maybe, maybe not. It could be that a lot of your team’s code churn is tied to circumstances beyond their control. That moves the ball into your court. Leastwise, code churn is worth understanding in detail because it is 100x less costly to catch a defect during the design phase than catching it during maintenance.
| Design | Implementation | Testing | Maintenance | |
|---|---|---|---|---|
| Defect Discovery Cost MultiplierAWS Code Deploy | 1x | 6.5x | 15x | 100x |
Source: IBM Systems Sciences Institute
As we discussed in Five Code Churn Tips for Engineering Managers, code churn is an important metric for gauging code quality that is often misunderstood. To summarize, code churn is the amount of change that takes place in a volume of code in a short period of time.
Code churn is automatically tracked by version control systems like Git, and calculated as:
Code Churn = Lines Added + Lines Deleted + Lines Modified
The more frequently code changes, the more likely it is to have defects (defect density). The more time spent changing existing code means less new code and functionality is being produced.
For a quick game of “Red Light – Green Light” there are several causes for code churn. While code churn, by itself, is neither good or bad – many of the reasons behind code churn are functionally negative.
We’ll take a look at each of these in some depth, their impact, how to spot them, and how to prevent, solve, or improve conditions contributing to unproductive code churn.
Case: Prototyping new projects and solving complex problems are a lot like writing the first draft of an essay in school. It can take a few tries just to come up with a good topic or the logic to support it.
Impact and Visibility: A significant amount of work or code ends up in the trash bin because, for whatever reason, the developer found it wouldn’t work or meet project requirements. Prototyping code churn is a natural and healthy part of the development process and can be seen in the work of all developers in the early stages of a project. Code churn should decrease over time as more and more of it is stabilized, passes tests, and goes through code reviews.
One of the rules of software development is to leave code better off than you found it. In many cases, that involves code churn. Focused renovation may involve refactoring code. Generally, it’s to be expected for code churn on a project to start high. Without other intervening issues, as long as code churn progressively decreases, you’re in good shape.
Solutions: Beyond reducing ambiguity, the main issue with prototyping is making sure developers are not creating custom solutions for problems solved by existing resources unless it’s specified in the project requirements. Every software development team benefits from a mature set of guidelines and work processes:
Custom created solutions are prone to be characterized by high code churn over a longer period instead of a steady decline. This may be an isolated occurrence where a developer is simply unaware of an existing solution. But some developers are driven by being able to show their creative potential and it’ll be reflected as a trend.
Case: Your client came to you with an MVP-style project. Three months into development, the client wants to add a couple of additional features.
Impact and Visibility: Adding features midstream involves a lot of additional unplanned work.
Changes to existing work are followed by a spike in code churn. Changes requests can theoretically come in any stage, but many can be pre-empted. Arguing with clients and executives is not a good idea, but you can present them the additional costs in time and money their changes will involve. And, if they’re okay with that, cool beans, no problem!
Solutions: A lot of change requests are avoidable, but it requires extra effort by the Project Manager and/or Account Manager. You need to verify that the “client” and their specialists are educated about their options. Those options are constantly changing in terms of devices, other third-party software, and the data both can collect.
Avoid Technical Debt Like You’re Borg goes into further depth, but good examples include 5G, Google Play and the App Store discontinuing support for 32-bit mobile apps, the activation of the EU’s General Data Protection Regulation, Apple ditching Intel chips, and so on. Managers of non-tech companies may not know all of the data they can access. If they discover possibilities later, they may want to include it.
Case: You asked for an app capable of handling large file uploads. You received an app that handles uploads of up to 20 Mb. But, by large, you meant 50 or even 500 Mb.
Impact and Visibility: When ambiguity is an issue, it is likely to reflect in elevated code churn in all phases of development with your team’s present and past projects. Software development inherently involves high levels of ambiguity. Ambiguity can be an issue depending on how tasks are defined in your project management software..
Solutions: Each team has its own tolerance for ambiguity. Mature teams experienced working together may have their own telepathic sixth sense or innate logic of the implied requirements of a vague task. Teams with many new members need tighter guidance.
Code churn due to ambiguity is not productive, but can be mitigated by:
If you’re curious, identify a few tasks or files with high code churn and compare with their descriptions in your PMS. Are the tasks vaguely defined? Ask your developers if they feel the tasks are sufficiently defined. Track progress after efforts to make task assignments more explicit.
Case: A developer who usually writes iOS apps is tasked to work on an Android app; or any scenario involving a mis-match in expertise.
Impact and Visibility: There are about 700 programming languages out there. Most developers are only fully fluent with a handful of them. High performance in one programming language does not infer they will perform similarly in others. When a developer is assigned a task involving a language they know but use less frequently, their code churn is likely to increase or their velocity will substantially decrease. Maybe both.
This case, iOS/Android, is interesting as mobile developers often, but don’t always know both languages or have equal proficiency in the tools and resources of each. They may be reluctant to volunteer that fact, suffice that performance metrics will pick it up.
Solutions: Software development analytics enables data-driven decisions when matching developers to projects and tasks based on programming language and code complexity. The same information is useful for pairing developers and assigning mentors. It’s ideal when you can get a strong iOS developer to work with a strong Android developer when you’re striving to improve your team’s cross-functionality and skills sets.
Case: The quest for perfection makes for a great philosophical debate but, “By the time you find perfection, your standards for it will have changed.” Each time the developer places the final touch to make their code perfect, they find another flaw and must extinguish it from existence. But in the process, and the process is everything… and everything is IN the process, new flaws emerge… and they must be eviscerated, too. And with it, the deadline came and passed as just another inconsequential moment in the eternal battle against evil imperfections.
Impact and Visibility: Code churn due to perfectionism is seen when a developer makes lots of changes in the mid-to-late stages of a sprint without adding new functionality. Perfectionism will, in the majority of cases, show up as a fairly consistent trend with specific developers. It’s easy to spot in their code churn history and may also be reflected in a pattern of delays with their assigned tasks. In software development, perfect code is not financially viable while often causing delays and missed deadlines. Plus, eventually, the code will be changed due to technical debt, tech churn, or new developers.
Solutions: Perfectionism can be a hard habit to break for some developers and requires delicately training them away from it. First steps in this direction involve talking with the developer about the big picture and reiterating what you mean by code that is good enough. The client may have millions of dollars and thousands of jobs riding upon launching on schedule with software that works “good enough.”
Case: The performance of one of your best and most experienced developers is steadily declining, code churn increasing, seems more detached, and less engaged.
Impact and Visibility: Burnout tends to show up as a gradual, but steady decline over weeks and months across several performance metrics. These include code churn, code efficiency, responsiveness, review coverage, possibly test coverage, active hours, and more. As it progresses, burnout may become more directly noticeable – in dress, behavior, attitude, social engagement, more sick days, etc. If these indicators aren’t acted upon, developers can become apathetic, not show up for work, contemplate career changes, and well, it can get worse.
Burnout is an occupational hazard for software developers (See: How To Notice And Prevent Software Developer Burnout). Everyone handles stress differently, but the cumulative long-term impact has several consistencies. Among them is the tendency for burnout to build incrementally and in a linear way and then go exponential, like a hockey stick.
Solutions: It’s common for managers to rely more heavily on their best developers for handling the most urgent or complex tasks. Be mindful of their workload, as excessive utilization ties directly into decreased performance with code churn and other metrics. Recognize burnout as something that most developers will experience to some degree. Burnout can be quickly reversed when caught early, so try the following to help keep all of your developers fresh:
Article updated: June 15, 2022
