Talk by Adam Tornhill from CodeScene
- Empirical data shows that there is no trade-off between speed and quality in Software Engineering
- Making the concept of code quality objective
- Software Engineers solve problems, not write code
- More time is spent on reading and understanding code than on writing code
- Significant percentage of engineering time (20-40%) goes to technical debt, but the real cost is most likely higher when taking into consideration the additional overhead of the additional number of engineers
Two Laws of Software Evolution
- Continuous change (a system must continuously adapt or it becomes progressively less satisfactory) → Quick reward
- Increasing complexity (as a system evolves, its complexity increases unless work is done to maintain or reduce it) → Slow feedback
- Decision making bias, future downsides are underestimated
- Code Quality is a subjective concept
- There isn’t a single number to represent quality, it will have to be measured through a selection of specific attributes
- Indicators at 3 different levels:
- Module and class design issues (Low Cohesion, Brain Class, Lack of Modularity)
- Function issues (brain methods, copy-pasted logic, primitive obsession)
- Implementations issues (deeply nested logic, complex conditionals,…)
- Example of visualising a big project split over multiple repositories (Ethereum)
- Agreement that code quality matters, but it’s still the first thing to be suffer
- Paper that is references during the talk
- Time-In-Development: Time from starting a (Jira) ticket to the commit
- Implementing a ticket in a healthy code base is significantly faster
- Important for velocity and speed to market
- Worst case time is significantly worse in unhealthy code
- Unhealthy code has significantly more bugs
- Bugs result in unplanned work which kills productivity
- Rethinking Productivity in Software Engineering
- What causes unhappiness amongst developers?
- Stuck in problem-solving, time pressure, working with bad code
- Create awareness through visualisations
- Fight hyperbolic discounting
- Build a business case: when working on a project in unhealthy code, the time estimate can go up a significant factor. A case can be made for refactoring.
- Increasing, not Diminishing: Investigating the Returns of Highly Maintainable Code
- Looking at value creation for the business (= velocity and defect reduction)
- Non-linear curve
- Not only healthy code is important, but also how engineers interact with it
- Prioritise based on change frequency (based on git commit frequency)
- Not all technical debt must be fixed, focus on parts with high change frequency