BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Adam Tornhill on Good Engineering Culture, Technical Debt and Ways to Reduce Inter-Team Conflict

Adam Tornhill on Good Engineering Culture, Technical Debt and Ways to Reduce Inter-Team Conflict

Bookmarks

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

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:

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT