Dave Farley on Taking Back Software Engineering

Show Notes

• 00:26 Introduction
• 00:47 One of the authors of the Continuous Delivery book
• 01:18 Software Engineering is a term that has come into disfavor in parts of the industry
• 01:41 The push back that says we’re not engineers we’re craftspeople
• 02:01 At the very hard end of computing you need genuine engineering disciplines to be successful
• 02:12 Applying engineering disciplines made a dramatic impact on the speed and quality of the development process
• 02:27 Drafting the ideas of Modern Software Engineering
• 02:41 Most of the previous definitions of software engineering have got it wrong because they tried to be too prescriptive
• 03:08 The principles for software engineering need to be so fundamental that they will remain true over time irrespective of the way development practices change
• 03:45 We have very little empirical measurement in software development today
• 04:01 In many ways software development is a fashion industry – we chose technologies, languages and approaches based on who if the most persuasive orator rather than empirical evidence
• 04:21 5 foundational principles for software engineering that will be durable, broadly applicable and broadly acceptable
• 04:38 Principle 1 We have learned that planned approaches to software development don’t work – some sort of iterative approach to development is necessary
• 04:49 Principle 2 Fast, efficient, high-quality feedback has a dramatic impact on our ability to move forward with confidence and quality
• 05:13 Principle 3 True experimentation is key – starting with a hypothesis and using the scientific method to evaluate make predictions and evaluate results
• 05:26 Principle 4 Working in an incremental way, building software in a modular fashion, growing complex products from simple components
• 05:37 Principle 5 Be empirical – test the results and gather real data based on what happens when the system is in production, learn from that and adapt
• 05:57 These are common-sense approaches which are often not practiced evidence
• 06:01 Most of software development is based around guesswork
• 06:31 Moving from guessing to testing hypotheses as an experiment
• 06:41 Extreme Programming and continuous delivery are genuine engineering disciplines because they are focused on the engineering practices that enable you to build high-quality products fast
• 06:57 A continuous delivery deployment pipeline gives you a wonderful experimental platform so you can try out ideas quickly and efficiently
• 07:18 This enables the ability to be genuinely agile – inspecting, adapting and reacting to what is observed
• 07:43 The need for team discipline to achieve these outcomes and
• 07:48 Example of a team Dave has worked on who applied the discipline needed and what they achieved
• 08:16 The advantage of starting with a clean-room delivery
• 08:31 The result was a hyper-agile, exceedingly disciplined team
• 08:43 Software development is an exercise in learning, exploration and discovery
• 09:01 The result of this way of working was the highest-quality codebase and the fastest development team Dave has ever worked with
• 09:15 This was not because of being smarter than others – it was because of the disciplined approach they took
• 09:40 To be able to truly experiment you need to be more data-driven; identify the useful metrics which will tell you about the state of your product
• 09:48 Examples of metrics that can be used in different contexts
• 10:12 The difference between an engineer and someone not applying that mindset is related to how much time is spent thinking about how and what can go wrong with the product
• 10:24 An example from Dave’s own experience around test driven development as a really important discipline
• 11:24 TDD applied in this way is a genuine experiment and it results in a higher quality piece of the product
• 11:38 Examples of other experiments applied at different levels
• 11:48 In a continuous delivery environment the deployment pipeline is a falsification mechanism – if a test fails the code is not good enough
• 12:40 The value of pairing in development and why it matters
• 13:13 Pair programming unlocks the capability of individuals and teams to learn 
• 13:38 Another foundational pillar of an engineering discipline is the need to continuously learn, because discover, exploration and learning is the fundamental nature of software development
• 13:55 Apply rigor to become better at learning – pairing achieves this
• 14:32 To help teams adopt pairing, encourage them to experiment with pairing to evaluate the value in their local context
• 14:41 This needs to be a determined effort lasting 2 to 4 weeks because there is a lot of learning about how to pair that needs to happen
• 15:14 The results that Dave has found from applying this approach in organizations he’s worked with
• 15:38 There will be a small group of people who genuinely can’t pair with others, you need to decide how to deal with that based on the organization’s needs
• 16:05 Dave’s story of interviewing and selecting people who have a mindset that links to the XP way of working
• 17:12 Some of these changes are generational – they are too profound a change for some people and teams to make
• 17:50 Examples of places where the title of Engineer requires registration and the adoption of a code of ethics
• 18:09 The lack of an enforceable technical standard is an issue
• 18:12 At some point there is likely to be a significant disaster that will be attributed to software which will result in a reaction at a societal level that will require registration and commitment to enforceable technical standards
• 19:18 The importance of also exploring ethical standards for software engineering
• 19:48 The challenges that these standards could have for the industry and the need for them
• 20:02 From a societal viewpoint, software development is a crucially important skillset and increasingly peoples’ lives and livelihoods are dependants on software so it is vital that we build these products to high quality and ethical standards
• 20:22 If people who build cars, airplanes or bridges were as lax as most software developers there would be many lives lost and lawsuits

Mentioned:

• Agile India
• Continuous Delivery book
• Extreme Programming
• Dave’s website
• Dave on Twitter and email