What is Work Breakdown?
Updated
Work types
LinearB divides work (code changes) into 3 categories:
New work - New work is brand new code that has been added to the code base.
Refactor - Refactored work represents changes to legacy code. LinearB considers code "legacy" if it has been in your code-base for over 21 days.
- Some degree of refactored code is acceptable and even required for improving systems quality.
- A large amount of refactoring in a single release is not recommended, as these changes have a higher probability of harming existing functionality.
Rework - Reworked code is relatively new code that is modified in a branch. LinearB considers any changes to code that was introduced or last modified less than 21 days ago to be rework.
- High levels of reworked code could indicate a quality issue in recent releases.
Interpreting work breakdown
Having a mix of each type of work is considered healthy: you don't want to undergo a major refactor at the expense of new feature development or build only new features without ever revisiting old work. Additionally, some rework is going to be inevitable: code review is designed to catch things that need to be reworked before going to production. But of course, if code is constantly being reworked, that indicates an issue with code readability, code maintainability, or feature scoping.
The right mix of work will ultimately depend on your specific code: if you're in a high-growth startup, you may be doing much less refactor work while building tons of new features. If you work at a bank, you may really focus on stability and security-oriented refactor work, with a smaller percentage of new features. The key is to make sure that the results you're seeing in LinearB support your team's needs and goals.
Viewing work breakdown
Click on the arrow icon in the top right corner to see all branches represented in your work breakdown graph.
Click on the graph icon to see your work breakdown over time.
Calculations
To calculate whether work is new work, rework, or refactor work, LinearB uses git blame. If blame reveals that a line of code did not exist in the commit chain leading up to the commit being evaluated, then the work is considered new work. If the line of code did exist in the commit chain leading up to the commit being evaluated, and was last modified more than 21 days ago, then the work is classified as refactor work. If the line of code did exist in the commit chain leading up to the commit being evaluated, and was last modified less than 21 days ago, then the work is considered rework.
Because the entire commit chain leading up to the commit being evaluated is taken into account (rather than simply running a diff against the release branch of the code), the rework/refactor evaluation should be accurate even if the last modification of a particular line was not merged back to the main release branch before being changed. This allows LinearB to track rework that happens during the code review process, for example.
