Let's explore some of the myths that you hear around XP development, and talk about why your developers should be using XP to create quality, well-crafted software.
3. Who knows what XP is?
Who would say that they work on a team that
follows XP practices?
Pop Quiz!
4. What is Extreme Programming?
Definition
Extreme Programming (XP) is an agile software
development framework that aims to produce higher quality
software, and higher quality of life for the development team.
XP is the most specific of the agile frameworks regarding
appropriate engineering practices for software development.
~ agilealliance.org
XP is an agile software development framework.
XP aims to produce higher quality software, and a higher quality life for the developers.
It’s the most specific framework regarding software development practices.
Radical communication
What is the simplest thing that will work?
Immediate feedback, (tests or from the business/customers)
Respect for the team, the code and the process
Kent Beck - “effective action in the face of fear” - courage to change direction, accept feedback or stand up for something better
Everyone together in a single open space to facilitate communication and flow of knowledge. No wizard caves!
Anyone needed to produce the software is part of the team (even business)
Facilitate face-to-face communication and share all knowledge (Dashboards and build monitors)
Slack - room to take care of the small stuff or overruns on estimates
Incremental Design - Let the work come out as you go. This doesn’t mean no design, but Big Design Up Front will cause extra unneeded work to be done.
Myths separated by category in which you’re likely to hear them.
TDD is hard, but so is software development.
Like all things, you need to practice TDD to get better.
Done regularly, TDD is no longer hard, it’s easy and comfortable.
TDD will give you 100% coverage
TDD is slow…
if you’re just learning how to use it.
if you’re more interested in results now, instead of quality later
TDD allows you to go faster as the project gets larger, as you know that changes don’t break previously written code.
The speed you get from having near 100% coverage throughout the development life-cycle easily exceeds the time it takes to practice TDD upfront.
Untrue! There are still defects in TDD written code. There are significantly less than code written without TDD.
TDD reduces production bug density by 40–80% - TDD - The Art of Fearless Programming - R. Jeffries and G. Melnik
What TDD does is allow QA to do their job as a customer advocate.
TDD reduces or eliminates the QA Hell that is regression testing.
Maybe, just maybe you do. But you’ve slower, you write more bugs, you communicate less effectively with the rest of the team. You’re knowledge stays with you. Maybe that’s the idea.
Most of the people I hear this from say it from a place of fear: for their job, imposter syndrome, etc.
No it’s not. It belongs to the company. Code ownership should be a shared ownership across the team. Shared ownership brings an importance to developing the right thing at the right time.
Teams that have shared ownership in their code create truly amazing products.
While pairing is great at bringing new people (or jr level developers) up to speed on a project or technology, Everyone has something they can learn from pairing.
Pairing brings about organic shared code standards and raises to level of the team as a whole.
Kent Beck wrote the book (literally) on Extreme Programming in 1999
Is it still relevant? The processes that we use to write well crafted software are just as relevant today as when the book came out in 1999
Refactoring isn’t about rewriting badly written code, although it can be.
Refactoring is
updating the code to work as it is currently needed
Reducing tech debt
Getting rid of repetitive code
Cleaning spaghetti and making it extensible and reusable
Because it will increase productivity over the life-cycle of your development
team cohesion, growth, shared ownership
Organic coding standards, knowledge transfer between pair partners
17% slower, but 40 - 80% less bugs.
When is?
If you could learn a development practice that lets you produce higher quality software at a faster pace, when would you want to have your team do learn to do it?
If you can’t trust your developers to work with security & ops to do the correct thing, why did you hire them?
No such thing!
1x Developer == 2 bugs/avg
10x Developer == 20 bugs/avg
XP is about allowing the team to develop software in a LEAN way
It encourages a DevOps mentality, not soloed teams
XP focuses on Technical Practices that produce quality crafted software.
Shout out to a great book that you all should read.
