One of the discussions I’ve had many times with clients has circled the topic of the decisions we make today in our work and how it will affect the cost of future work. We are always endeavouring to not paint ourselves into a corner.
Common wisdom would say this is impossible, at least the common wisdom I’ve been privy to in my programming career. This is where Extreme Programming (XP) would deviate from the norms I’ve seen though. XP contends that it is possible to stop the cost of software changes from rising as time goes on.
This is part of my Should I Read It podcast. Make sure you don’t miss an episode by subscribing to Should I Read It.
This seems like a very bold claim, so let’s dig into what XP is and how we can use it to do software better.
It’s all about software process
The biggest idea to get across before you dive into XP is that you must follow the process. Simply having it up on some board as a set of values you adhere to is useless. You must do the process for it to work.
No matter how well-intentioned your values, if your methods aren’t practiced, they’re useless. A method that recommends voluminous design documents is just creating busywork if no one ever reads the documents, let alone updates them.
This goes for anything in your business. If you have a customer follow up process and you never do it, you may as well not have it.
In XP there are four variables for projects.
- Time
- Scope
- Resources
- Quality
Where most projects feel they can add scope and not change time, XP says that it’s impossible without a trade off in another area. This is where XP asks you to make a new agreement with your clients.
XP suggests a different strategy. Agree as a team – including the customer – on acceptable level of quality. Agree to consider that time and resources are fixed. The only remaining question is that of scope. What will be delivered? The customer will set the priorities for individual features. You will work on them in turn. The software will always be kept in a releasable state.
This agreement does mean that a client must be okay with not getting all the features they originally wanted if you hit a bump in the road. When a change happens, the client must be okay with bumping something else off the list in favour of the changes.
The Core Values of XP
After the four variables in a project, XP has four values.
1. Communication
This is easily summarized as good communication makes a project. Bad communication sinks it.
Removing the communication barriers between customers and developers increases flexibility. Sharpening the decision between business and technical decisions helps you make the right decisions. Communicating clearly about goals, status, and priorities allows you to succeed.
I’ve said before that if your client has to send you an email with a question about where things are, you’ve failed in your work as their developer. You should be sending them updates every Monday and Friday. If that sounds hard, I wrote a book to help make it easy.
In communication, customers choose which tasks provide the most value but they don’t get a say in how things are done. That is a decision for the developers to make.
2. Feedback
Tied tightly with communication is feedback. You must iterate quickly and get feedback from your customers.
Rapid feedback reduces the investment of time and resources in ideas with little payoff.
With rapid feedback on your projects, you don’t build stuff customers don’t care about. You build the minimum viable product and then you ship it. With the feedback you get from that MVP, you build the next feature that the customers want.
3. Simplicity
I opened this review up by saying that it’s a commonly accepted thought that projects cost more to change later. XP’s answer to this is simplicity.
See, trying to build some scalable system that will in theory exist in the future is impossible. You don’t know which part will need to scale yet because you haven’t hit the issues that will come.
Solve today’s problem today. Tomorrow when you have a new problem you’ll know enough to solve it. So solve it.
4. Courage
The final value ties all the others together. It takes courage to tell your client that you are behind schedule and they need to decide which features they want to be ready for the deadline.
It takes courage to be half way down a path and then to scrap the code because it’s not working.
It’s been my experience that those hard discussions are built up to be infinitely harder than they are. I’ve never had one that didn’t result in a huge weight being lifted off my chest when I finally talk to the client.
So have the courage because that’s what makes a great business owner.
You cannot make time or find it
You don’t have a time machine, nor do you find time like change in the couch. You have a certain number of productive hours every day and you must use them. You can’t make more.
This is where we address client deadlines.
Rather than scrambling to meet an impossible deadline, work to your normal pace. The amount of work you can do is constant — the only real question is which work to do.
Instead of rushing to meet a deadline in some death march, for which software development has become famous, work at your regular pace. A long career is marked by rest, not by deathmarching to a deadline. If you do “find” those hours you can be sure that the next time something comes up the client will expect the same thing.
The deathmarch never ends.
That brings to and end the first section of Extreme Programming. From here on we get much more concrete into what you need to do to get XP going in your team starting with the coding practices.
The 4 Coding Practices of Extreme Programming
1. Code and design simply
This goes back to the simplicity value we already cited. Solve tomorrow’s problem tomorrow.
Rarely can anyone anticipate a future feature sufficiently to design and implement it correctly. You will know enough to create a new feature when the customer can describe it.
2. Refactor Mercilessly
Refactoring should be done all the time. When you touch a piece of code a second time, see if you can make it better without breaking anything.
By keeping up with refactoring all the time you stop the overwhelming task later. You also preempt the idea that you must throw the whole thing out because it’s just so bad now.
3. Develop Coding Standards
The most hated commits of one of my friends is “fixing white space”. But you’re going to get a bunch of them, which toggle things back and forth, if you don’t have coding standards.
Take the time to build them for your project and then stick to them. It will reduce the frustration of everyone.
4. Develop a common vocabulary
On top of coding standards, we need to make sure that we all mean the same thing. When we say “customer” do we mean the person paying for the software, or the person that pays them?
To make sure that you don’t make mistakes in your programs and to make sure that your meetings move effectively, you need to have a centralized vocabulary.
The 4 Developer Practices of Extreme Programming
After the code based standards, we dive in to standards for developers that are adopting XP.
1. Adopt Test-Driven Development
To be a test-driven development shop a feature is only finishing when it has full test coverage. When you have a bug, you first write a test to expose the bug and then you fix it.
Writing a test first helps ensure that future updates don’t bring the bug back because you’ll have a failing test now.
2. Pair Programming
Pair programming means you have two programmers for a task. This helps enforce the coding standards because your less likely to take shortcuts when you have someone looking over your shoulder.
Pairs should form for a task and then reform for the next task. This also helps spread knowledge around the organization.
3. Collective Code Ownership
No you don’t own the code you wrote. You will not be the only person working on a specific integration. Everyone should be empowered to work with the code. This stops silos and prevents Sally getting hit by a bus and then no one can touch her code anymore because it’s a pile of sticks waiting to fall.
4. Integrate Continually
Don’t perform monolithic updates. Finish a set of tasks over a week or two and then deploy them. Any issues that arise will be easier to attribute to certain changes.
Many companies will now deploy many times a day. I deploy whenever I have any change to my site. Most of my client sites do that as well, with multiple deploys a day happening.
The 4 Business Practices of Extreme Programming
Building a successful software project requires far more than just coding. A beautiful, elegant, and comprehensively tested project is useless unless it meets actual customer needs.
1. Add a customer to the team
If it’s all developers in the room, you’re going to be talking about code and a bunch of nerdy stuff. You need a customer in the room to help keep everyone focused on the value that is brought be teach feature.
Once this has been done for a while, the job gets smaller because the developers will already understand the business issue behind the code. They’ll be making better value decisions.
2. Play the planning game
The planning game is designed to help maximize the value that each feature brings. The customer writes down stories. Then the developers estimate how long each story will take to complete.
With that information the customer is empowered to decide which stories bring the most value to their business. They choose what gets worked on.
3. Release Regularly
Similar to integrating continually, releasing regularly means that you show your work to clients lots and lots. I try to have something new to show clients every 3 – 6 hours of work I put in.
4. Work at a sustainable pace
Everyone has a natural level of productivity. It will vary from person to person, but everyone has a limited amount of physical, mental, and creative energy. Every hour of work costs energy.
We’ve already talked about this in the first section so I won’t go into detail. Remember that the all-nighter is a sign of failure now.
With our 12 practices listed, we head into the different events that take place if you adopt the Extreme Programming methodology.
Iteration Planning in XP
An iteration will last from 1 – 4 weeks usually. That means that your stories should be a few days work at most. Keeping stories small means you’re practicing simplicity.
While your estimates for hours will assume no interruptions and peak programming effectiveness, that almost never happens. Iterating fast means that you can see how many real hours you get done in a cycle. With that information you can plan more or less work for the next cycle.
It usually takes a few iterations to get a firm handle on the speed at which your time can work.
As your planning an iteration, make sure that you do the most risky tasks first. Get them out of the way and then move on to the things that you’re more sure of. This is like Brian Tracy’s idea that if you eat an ugly frog first thing in the morning, the rest of the day is easy.
XP also calls for daily stand ups. This helps form and reform pairs as people are interested in the problems that come up during the standup. This also keeps everyone informed about what’s going on.
We’ve talked about a few things, like stories, already but we haven’t defined exactly what they are so let’s look at the artifacts of Extreme Programming.
Story Cards
Story cards answer the question what should be done? Each card describes a desired feature of the software project in story form — a sentence or two from the customers perspective.
A story is only ever a single feature. If you’re using “and” in the story, it’s likely two items not one. Customers write story cards.
Task Cards
These are written by developers for developers and answer how something should be done. Remember, customers don’t get a say in how something should be done.
The Bullpen
In XP The Bullpen is one of those terrible open offices that are so popular. Despite the growing research showing that open offices distract way more than they help focus.
Those are the only artifacts in Extreme Programming, and it could be convincingly argued that you only need story and task cards. You could do a daily stand up and then retire to quieter offices as a pair. You’ll avoid the distraction of others and still pair.
Reforming pairs regularly, which is something that XP calls for, will help the collaboration stay high without the distractions.
The Four roles of Extreme Programming
We’ve already talked about the customer and the developer roles a few times so we’ll only look at the two new supplementary roles that XP introduces as it discusses the roles needed for a successful project.
Tracker
The tracker in XP keeps an eye on the schedule. It is there job to make sure the team is aware of how far ahead/behind they are and to communicate that to the customer so that value judgements can be made about the work in progress.
Coach
The coach is an XP expert who helps keep the team standards high in their XPness. I’m sure that’s a word…!
Mostly Repeating Itself
While Extreme Programming has been repeating itself a bit already, Part VI is almost totally repeat. It’s redeemed because it’s so short.
Part VI reminds us to solve today’s problem.
To do it the simplest way, not just the fastest way.
“Simple” is different from “Quickest to write” and very different from “The first idea that comes to mind.” Discovering the simplest possible solution is difficult.
Finally it says that XP people need to be scripting repeated tasks so that they don’t waste time doing them over and over.
What is needed to adopt Extreme Programming?
The final section is all about the specifics of what you need to adopt XP in your business.
First, you need a team of people to work with. If you’re working on your own you can’t pair program because there is no one to pair with.
Really, this tells you that you need all the things we read about in the 12 practices of XP already. It’s good that the book is specific about the things you need, but you’re hardly blind to them if you’ve read the book well already.
Should You Read Extreme Programming?
The short answer is yes, but be ready to skim more as you get further in the book because the repetition is high. Learning about the XP process will help you even if you don’t have a team and can’t do parts of it.
Simply adopting Test Driven Development will help you write better code. You’ll also write code that’s less prone to random bugs and you’ll know when your changes break other work already done.
Purchase Extreme Programming on Amazon
Photo by: kwl