Goodbye Waterfall hello Agile
This book, when it came out in the 90s, was extremely controversial. Agile was beginning to take serious hold as companies and programmers were fed up with the shortcomings of the Waterfall* methodology.
* Waterfall was characterized by a lengthy planning period where the project is planned from start to finish. It was extremely costly and inflexible when business requirements changed (which they often do)
There are two main flavors of Agile - Scrum and XP. Scrum of course is the more popular and is being used by many companies.
What is Extreme Programming (XP)?
To start what even is Extreme Programming (XP)? In short, it takes all of the best practices that we know work - to the EXTREME. Here's an excerpt to highlight some of the ideas behind it:
If code reviews are good, we’ll review code all the time (pair programming).
If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
If design is good, we’ll make it part of everybody’s daily business (refactoring).
If simplicity is good, we’ll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).
If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
If integration testing is important, then we’ll integrate and test several times a day (continuous integration).
If short iterations are good, we’ll make the iterations really, really short - seconds and minutes and hours, not weeks and months and years (the planning game).
Some of these ideas are as old as programming itself but Kent warns that the XP response to these ideas WILL be counterintuitive and "extreme."
4 Values of XP
XP is defined by its 4 values:
Communication - since failures in projects are typically linked to under-communication let's communicate as much as possible with pair programming, unit testing, and task estimation.
Simplicity - instead of building something complicated today that's potentially never going to be used - opt to keep things simple today and change things that need to be changed tomorrow.
Feedback - there is a constant feedback loop - every minute when programmers are writing unit tests they get responses from the system. Customers are writing functional tests. The progress of the team is tracked constantly. Most importantly programmers get constant feedback from pair programming and reviewing code together.
🔥 Fav quote from this section:
Writing the test gives you a focus for just how simple the system can be—until the tests run, you're not done, and when the tests all run, you're done.
Courage - Acting on Simplicity, constant Feedback, and Simplicity, teams are very close-knit and make courageous decisions together. One person may have a crazy idea that takes courage to implement. The team may decide that a certain decision they made needs to be scrapped - it takes courage to recognize and act on it.
12 Practices of XP
Based on the 4 principles from above we get these 12 practices that help maintain these 4 principles:
Rapid Feedback - the faster you get stimulus to an action the quicker you can judge and adapt accordingly. For programmers let's do this as quickly as possible: let's get feedback, respond, and put it back into the project to make it better.
Assume Simplicity - "Treat every problem as if it can be solved with ridiculous simplicity." This is where things get counterintuitive though! We're taught to prepare for the future. But we have to solve today's problems to the best of our ability (with testing, refactoring, and communication) and trust that we can handle complexity in the future.
Incremental Change - Do everything in small steps! Adoption of TDD, designing, adapting team for growth, plans, etc.
Embracing Change - "The best strategy is the one that preserves the most options while actually solving your most pressing problem."
Quality Work - Do your damnedest and you'll get a lot out of it. If there's no quality - "... you don't enjoy your work, you don't work well, and the project goes down the drain."
Teach learning - There's a lot of room for flexibility - some practices will be forced and certain, and others are looser as the team tries to find the best solution. Teach individuals strategies to find solutions.
Small initial investment - You can't throw a ton of money into a project initially and expect it to take off. Things need to start slow. There need to be clearly defined responsibilities where productivity is high and people feel that they're killing it.
Play to win - Kent claims that most software development he sees is played "Not to lose." Losing is characterized by a lot of meetings, and development "by the book" where people are following practices that inevitably fail but are covering their asses to avoid being blamed.
"Software development played to win does everything that helps the team to win and doesn't do anything that doesn't help to win."
Concrete experiments - XP is characterized by a lot of experimentation - tweaking the design, changing team dynamic, etc. - if there is no baseline testing and performance measurement there's a chance the team is hurting itself.
Open, honest communication - Teams should be prepared for honest, open feedback and handle it well. They need to be able to discuss problems in the code written by people on the team, they need the freedom to express fears, frustrations, and anger, and get total support. There should also be an open discussion between the business and management with no fear of delivering bad news.
Work with people's instincts, not against them - XP works with people's short-term interests by heavily involving them on a winning team, with tons of interactions with other members, and the freedom to create and develop kickass software. This is what makes XP work.
Accepted responsibility - Instead of being told what to do on the team, team members willingly accept responsibility for things that benefit the team.
Local adaptation - Kent emphasizes that XP doesn't mean that he gets to decide how your team develops - that's up to you! It's up to you to be scientific about the processes you implement, measure, tweak and adjust over and over.
i.e. Remote teams would look very different doing XP than a full-time in-office team
Travel light - Kent compares the team to intellectual nomads. They're constantly shifting directions when business requirements change, or when the team moves in a new direction. They only carry what produces value for customer - "tests and code."
Honest measurement - Choose measurements that best benefit everyone. LOC is a useless measurement.
4 Basic Activities:
Kent explores the basic activities of software engineering: coding, testing, listening and designing.
He says:
So you code because if you don't code, you haven't done anything. You test because if you don't test, you don't know when you are done coding. You listen because if you don't listen you don't know what to code or what to test. And you design so you can keep coding and testing and listening indefinitely. That's it. Those are the activities we have to help structure:
Coding
Testing
Listening
Designing
Practices of XP
The Planning Game - Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
Short Releases - Ship the "most valuable business requirements" in small releases.
Metaphor - A "10,000-meter view of the system." Every XP project is guided by a metaphor to quickly understand the relationship between elements in the project.
Simple Design - The right design is one that:
Runs all the tests.
Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies.
States every intention important to the programmers.
Has the fewest possible classes and methods.
Kent mentions the modern advice "Implement for today, design for tomorrow." He emphasizes - knowing the future is quick to change - from business requirements to team ideas evolving - writing functionality because we think we might need it is crazy. The XP approach is simple: "put in what you need when you need it."
Testing - Since programmers and customers write tests, unit and functional respectively, the confidence these tests produce become a part of the program they're creating. This makes it more capable of handling change.
He emphasizes you have to begin with tests but not to test every minutia - like every method and other small details- but instead the production methods and things susceptible to break. Let your experimentation and then subsequent intuition guide you.
Refactoring - Knowing that things change quickly - we want to be able to go into the code and rapidly change things when the time comes. To make things easy to change we constantly are refactoring - making things simpler while keeping tests green. Avoiding writing quick, messy code we instead focus on writing simple code, even though it may take longer to implement.
Pair Programming - People on the team will constantly pair with different people depending on tasks and who's avaiable. One person is typing the code and the other is thinking strategically - considering the system as a whole, a future test case, and constantly thinking about simplification of the system.
Collective Ownership - There are two other models of code ownership:
1. No ownership - people changed whatever part of the code they wanted to suit their needs. This results in a massive codebase that quickly becomes unstable.
2. Individual ownership - sections, or the entire codebase, are owned by one person. Teams had to wait for that person's availability and then were screwed when that person leaves the company because no one understands it.
Contrastly, in XP everyone owns the code. If a paired team sees an opportunity for improvement they take action and improve everyone's experience.
Continuous Integration - The team should constantly be integrating their changes into the current release and merge it when tests fully pass (100%) If the tests aren't passing it's time to start over with where it's broken.
40-Hour Week - Our brains are constantly going to be creative and running, so we need to be fully rested. There shouldn't be 2 weeks of overtime in a row. If there are - that's a symptom of some serious problems that can't be solved with overtime.
On-site customer - Bring someone into the project who will be the end user of the system being developed. They will be available for questions, resolving disputes, priorities, and testing. This person will result in the project being built quicker. There's an obvious objection from companies with this idea: "We can't afford to dedicate one extra person to your team for this" to which you should respond: "If having the system doesn't bring more value than that one person's productivity then that system shouldn't be built."
Coding Standards - With constant changes being implemented in code there's a serious risk for problems in the code like different patterns and practices. To combat this XP teams implement standards which are adopted by every team member.
The case for Pair Programming
Kent emphasizes that pair programming is not one person coding while the other just watches, or one person tutoring the other. It's a dynamic interaction with constant communication.
One person strategically views the code based on the bigger picture of the system and actively offers suggestions and comments. The other is implementing the tests first and then coding for the feature at a micro level.
He suggests that the reader view pair programming as two people simultaneously programming. Both people are analyzing, designing and testing. "It is a conversation at many levels, assisted by and focused on a computer."
But what about productivity? I can't afford two programmers to work on one task!
Kent notes that a pair is more productive than two individuals with their separate work. The resulting code quality is so much higher - it's incomparable.
Why Pair Program?
It results in a higher code quality that works with the overall system. It often results in code that is dead simple. It helps everyone on the team take ownership of the codebase - understanding how everything works together. It protects the code from external stress. In times of stress, people skip testing (this one time), write a pile of shit just to get a feature in, don't change complex code into simpler code. You think you can do any of that with a partner watching? Not a chance.
Testing - the XP way
Everyone knows that they should write more tests (hopefully) but nobody likes doing it - me included!
I love Kent's analogy for XP testing:
Here's what XP testing is like. Every time a programmer writes some code, they think it is going to work. So every time they think some code is going to work, they take that confidence out of the ether and turn it into an artifact that goes into the program. The confidence is there for their own use. And because it is there in the program, everyone else can use that confidence, too.
The idea of confidence becoming a part of the program itself is beautiful.
This confidence enables us to constantly refactor and create without worry of things breaking. When tests are failing it gives insight into a part of the system that is broken and should immediately be resolved by the team!
Why test first before coding?
XP focuses on simplicity. When you write code to make a test pass - the code's direct purpose for it existing - you are forced to keep that code simple into tested chunks.
Testing first ensures that programmers don't make mistakes. When you're building a feature without testing first - you're logically approaching that problem and figuring out how it ties to the business requirements all at once! It works but can lead to messy code. When testing first you lay out your thought process and how it corresponds to the requirements - in the form of tests - that you can complete one manageable piece at a time.
The testing software gives you immediate feedback to indicate your status and how your code is doing in the system: greenlight - "ok I know it works." Red - "okay I need to continue until this passes."
What do you test?
You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it. If I told you to test absolutely everything, pretty soon you would realize that most of the tests you were writing were valueless, and, if you were at all like me, you would stop writing them. "This testing stuff is for the birds.
Kent states that testing is a bet. You assert that the code works a certain way and when it doesn't you have to figure out why it's working unexpectedly because the code is smarter than you.
Who tests?
Programmers - with unit tests that always run at 100%
Customers - with functional/ acceptance tests, story by story, for the features of the application.
How to adopt XP?
Kent suggests that teams adopt one practice at a team - typically starting with "Testing" and the "Planning Game" due to most projects being plagued with quality and imbalance of power between business and devs.
Here's a guide to adopt XP (from the book):
Pick your worst problem.
Solve it the XP way.
When it's no longer your worst problem, repeat.
Can XP be adopted for existing teams?
Certainly but it's going to be challenging. Kent says:
Adopting XP with a new team is a challenge. Adopting it with an existing team and existing code base is even harder.
Not only do teams have to work on implementing XP one practice at a team, constantly adjust their approach to best fit their team, and get management on board with this new practice, but also keep deliverables at an acceptable rate. It's an uphill battle.
My Thoughts
I want to create the very best team that I possibly can. I want all of my team members to feel fulfilled in their work, truly enjoying the tight-knit team dynamic, where they can spend more time with their loved ones (40-hour work week), writing scalable code that is quick to adapt to constantly changing business requirements. Ultimately I want to build a team that has the perfect balance between kick-ass, fulfilled, and creative. Practicing XP leads to all of these being fulfilled. Going forward I am adopting XP.
I truly think this book is with your time!