Compare the differences between Code Climate Velocity and LinearB
How does Code Climate Velocity (launched 2011) compare to LinearB (launched 2018) over 53 features that NoteApps indexes? We have found & documented 17 features in Code Climate Velocity vs 28 features in LinearB. A complete accounting of their feature availability is provided below.
If you would like to compare other apps, try our app comparison tool. If you would like to see screenshots for each feature, click the link below each app for "Full details & screenshots."
|
Code Climate Velocity has 17 cataloged features
LinearB has 28 cataloged features
Difficulty of switching between apps:
Maximally similar,
switching should be a breeze if an importer exists
14 overlapping features
offered by both
Want some help switching apps?
|
|
|
|---|---|---|
|
Code Climate Velocity
advantages
No categories were found where Code Climate Velocity held a substantive feature advantage
LinearB
advantages
|
Code Climate VelocityLaunched 2011
|
LinearBLaunched 2018
|
|
Code Quality
Instrumentation of code quality metrics
|
||
|
Bug-fixing work graph
Graph of how much recent work has been spent on bug-fixing
|
||
|
Copy/paste graph
A graph show how much duplicated code has been generated
|
||
|
Copy/paste graph => Copy/paste within commit
Within a particular commit, the amount of copy/pasted code is graphed
|
||
|
Copy/paste graph => Copy/paste within repo
How many duplicated blocks of code exist across the entire repo
|
||
|
Cyclomatic (or equivalent) complexity analysis
Graph of the cumulative complexity (often expressed as "cyclomatic complexity") per file
|
||
|
Legacy refactor graph
Graph shows how much work is being done to refactor legacy code (by deleting, moving, or updating it)
|
||
|
Tech debt directories
A graph or table shows the directories that are deemed highest in tech debt
|
||
|
Tech debt files
Which files have the highest percentage of defects during a chosen time range
|
||
|
Test code graph
How much energy/volume has been dedicated to writing & maintaining test code
|
||
|
Developer Experience (DevEx)
Analytics to measure the experience of the team's developers
|
||
|
Active days with commit
Manager can be notified when developers are complete a commit during a worked day
|
||
|
Deep work percent
What percentage of the week was available for developers to undertake uninterrupted programming
|
||
|
Documentation coverage graph
The cumulative energy or work volume spent writing or maintaining repo documentation
|
||
|
Employee Net Promoter Score (NPS)
Developers can be surveyed for what percent would recommend their work environment to a friend
|
||
|
Progress consistency graph
A per-hour graph is available to indicate whether certain times of week tend to prevent productive work
|
||
|
Satisfaction/sentiment survey
Manager can measure their team's satisfaction via a configurable developer survey
|
||
|
Satisfaction/sentiment survey => Anonymized satisfaction survey
Surveys can be configured to allow (or obligate) anonymous responses
|
||
|
Developer Productivity Measurement
What possibilities does the app offer with regard to evaluating the capabilities of an individual developer?
|
||
|
Blended measurement is featured
The company spotlights at least one "summary" metric that, they purport, collectively shows team velocity over time
|
||
|
Changed Lines of Code Graph
|
||
|
Commit Count Graph
|
||
|
Notification on above average performance
|
||
|
Notification on below usual performance
|
||
|
Stack-rank [Anti-Feature]
A "leaderboard" where developers are put in order of performance is available. EngineeringAnalytics staff recommends against this feature, but still tracks it for completeness.
|
||
|
Google DORA
Features pertaining to Google DORA
|
||
|
Change Lead Time Graph
A graph of the average time from "first change" to "deployed"
|
||
|
Critical defects
Site allows critical defects (the unit of "site defects" and "time to repair") to be recorded and resolved
|
||
|
Critical defects => API to mark resolved
An API call can be utilized to designate defects as repaired
|
||
|
Critical defects => Entered via UI on site
|
||
|
Critical defects => Recognized via issue
A Jira ticket with one or more fields of a particular value (e.g., "Severity" of "Very high") can be auto-interpreted as a defect
|
||
|
Defect Rate (%) Graph
|
||
|
Deploy Frequency Graph
|
||
|
Deploy tracking
Repo deploys are recorded
|
||
|
Deploy tracking => Recorded via API
|
||
|
Mean Time to Repair (MTTR) Graph
Critical defects are tracked and presented as a graph of the team's MTTR
|
||
|
Historical Performance Stats
What charts, graphs and related features are available to see how the team has performed in the past vs. present?
|
||
|
Annual review
An report is available that summarizes the past months (configurable, to at least 3, 6 and 12) of an individual developer's achievements
|
||
|
Blended Team Progress Graph
Graph that blends team performance metrics together as a convenience to confer overall progress
|
||
|
Issue Tracker
What features are available to help a team stick to implementing features & improvements directed by the team's issue tracker (e.g., Jira)
|
||
|
Bug Work Graph
Illustration of the relative volume of developer work on fixing bugs: either tickets with "bug" label, or tickets otherwise inferred as bug work
|
||
|
Issues by Size Graph
Issues are graphed by the volume of work that was applied to them during a time range
|
||
|
Unplanned Work Graph
Illustration of the relative volume of developer work that was applied to working on issue tracker tickets, vs. unattributed work
|
||
|
Pull Requests
Features and notifications pertaining to pull requests
|
||
|
Abandoned (No recent work)
Pull requests that haven't received any work over a long duration generate a notification
|
||
|
Abandoned (closed without merge)
Notifications can be generated when a pull request is closed without being merged
|
||
|
Code Review
An on-site tool is available to review and comment upon the code that implements a pull request
|
||
|
Cycle Time ("First Change" to "Merged") Graph
|
||
|
Cycle Time ("First Change" to "Merged") Graph => Notification thresholds can be set
Threshold can be chosen to be notified when too much time passes between "First Change" and "Merge"
|
||
|
Lead Time ("First Change" to "Deploy") Graph
|
||
|
Lead Time ("First Change" to "Deploy") Graph => Notification can be set
Threshold can be chosen to be notified when too much time passes between "First Change" and "Deploy"
|
||
|
Pickup Time ("Open" to "First Review") Graph
A graph summarizes the team's running average time from "PR open" to "first review," sometimes referred to as "Pickup Time"
|
||
|
Pickup Time ("Open" to "First Review") Graph => Notification thresholds can be set
The user can choose a threshold at which to receive notifications when a PR has exceeded the "open" to "first review" target
|
||
|
Review Time ("First Review" to "Merge") Graph
|
||
|
Size Graph
A graph of the "total mass" (commits, blended metric, etc) for PRs opened
|
||
|
Size Graph => Notification thresholds can be set
Notification can be automated when a PR exceeds size target
|
||
|
Target for "Test" code
A threshold/notification can be set for the amount of code/energy dedicated to tests (unit, integration, or system)
|
||
|
Unreviewed When Merged Graph
A graph of the percentage of PRs that were merged without receiving a non-bot review
|
||
|
Sprint/Weekly Progress Indicators
What features are available to track day-to-day progress, including progress on the team's sprint, if sprints are used?
|
||
|
Burndown Chart
A chart depicts how much work remains for the current sprint
|
||
|
Time to Complete Estimate
A graph or similar visualization depicts the projected time to finish the pending Sprint tasks
|
||