This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast Shane Hastie, InfoQ Lead Editor for Culture & Methods, spoke Adam Tornhill of Empear on combining psychology and software engineering, technical debt.
Key Takeaways
- The problems in software engineering are not technical they are almost always people related
- A lot of technical debt is not actually technical in nature – it is due to organisational and social factors
- Research that shows that the number of developers who work on a block of code is a predictor of the number of quality issues that code will have
- There is a cuttoff point above which adding more people to work on a codebase becomes a negative return is fairly low
- Safety to be able to admit to not knowing, collaboration and constant learning are key to a healthy engineering culture
- Complex areas of a codebase which change frequently are the best targets for technical debt reduction - hotspots
- Inter-team conflict is inevitable unless you have an engineering culture where there is a clear and compelling common goal
Subscribe on:
05m:10s Introductions
01m:10s Combining an interest in psychology with software engineering
01m:35s Exploring why it is so hard to build software
02m:00s The problems are not technical they are people factors
02m:25s Code is written by people and psychology is about how people work
02m:35s A lot of technical debt is not actually technical in nature – it is due to organisational and social factors
03m:20s We mistake organisational problems for technical issues
03m:50s A lot of code end up being written by many people over a number of years
04m:15s The more people who work on a part of the code the harder it is to build a stable long-term mental model of the codebase
04m:45s Research that shows that the number of developers who work on a block of code is a predictor of the number of quality issues that code will have
05m:05s While one-person, one codebase is the ideal it is also high risk and you need other techniques to overcome those risks
05m:20s Code reviews are vital for high quality code
05m:40s The conscious tradeoffs that need to be made between number of people working on a codebase and the risk of single point of failure
05m:45s There is a cuttoff point above which adding more people to work on a codebase becomes a negative return is fairly low
06m:10s Example of putting more people on a problem resulted in more than doubled the duration of the project
08m:00s Contrasting pair debugging and pair programming
08m:25s The research on pair programming was mainly done on university students, which is not a useful comparison for commercial development environments
08m:40s Some reasons why code reviews are valuable – defect identification & reduction, social pressure to be more careful and knowledge sharing
09m:55s Build peer review into the engineering culture of the organisation
10m:45s What makes a productive engineering culture
10m:55s Safety to be able to admit to not knowing and to make mistakes
11m:05s Collaboration and constant learning are key to a healthy engineering culture
11m:35s To encourage a good engineering culture the leader needs to model the behaviours you want to see
11m:45s The leader’s responsibility to remove obstacles
12m:00s What is the process for buying a book? If it requires authorisation and approval then the organisation doesn’t really have a learning culture
12m:35s The ways the term technical debt is misused
13m:01s Just because some code is bad (or you don’t like how it was written) doesn’t make it technical debt – it’s only technical debt if we have to pay interest on it (it needs to be changed)
13m:35s Prioritise the technical debt you really need to fix
13m:50s Technical debt has a time dimension – a block of bad code which works and doesn’t need changing shouldn’t be prioritised
14m:50s There are some parts of any codebase that need to be changed frequently, technical debt in these areas matters
15m:10s Pareto principle in defect density
15m:45s Mine the version control history to see which parts of the code base change frequently and prioritise work around them – probably 4-5% of the codebase
16m:30s Add complexity as a second dimension; complex areas which change frequently are the best targets for technical debt reduction - hotspots
17m:20s Find the reason for an area of code becoming a hotspot
17m:30s Low cohesion is the number one reason that code becomes a hotspot
17m:40s Poorly understood domain concepts lead to lots of churn in the code that implements them
18m:00s These are problems which we know how to fix, in practice the level of churn makes it hard to simplify the code
18m:40s You need to consider the organisation social perspective as you refactor code
19m:10s Conways law and Brooks Law still apply
20m:10s Conway’s law drives us to separate concerns, however there is a price to be paid in inter-team conflicts
21m:00s Exploring how churn in the codebase can be visible evidence of inter-team conflict
21m:15s The information in the version control system exposes the social aspects of team collaboration
21m:50s Inter-team conflict is inevitable unless you have an engineering culture where there is a clear and compelling common goal
22m:35s The motivational value of knowing how your contribution fits into the bigger picture
23m:25s Build a culture where people care about what they build, and encourage learning
23m:45s Put numbers on your technical debt – don’t rely on gut feelings
Mentioned:
