One of the key XP (Extreme Programming) Practices is that of Pair Programming � two programmers working side-by-side at one computer collaborating on the same design, algorithm, code or test. The XP advocates state that higher quality products are produced faster, inspite of what appears at first sight to be an overtly redundant, wasteful use of programming resources.
The interesting thing that I have found is that when I teach SCM training courses with hands-on exercises (where people work through exercises against a pre-prepared repository), I usually get much better feedback and results if those present do the exercises in pairs.
Benefits
The advantages that I see are:
- a higher level of “hubbub” in the room – an indication of information exchange and reinforcement, resulting from more discussions both within and between pairs
- greater willingness to ask questions of the trainer
- faster progress through the exercises
My feeling is that pairing gets over a variety of inhibitors. It is quite easy when doing exercises to get stuck thinking you ought to know the answer (usually in the materials presented in the last session), and people work away for quite long periods without progressing. More importantly from a trainer’s point of view, people are often somewhat reluctant to ask questions and thus show that they have a problem (this tendency can vary significantly between different nationalities).
There are other factors at work:
- if there is an active internet connection available on the machines then individuals are more likely to surf the net or check their emails than a pair
- a pairing of more/less experience people brings greater knowledge transfer
Disadvantages
Some people find it inhibiting to work in a pair. They have a certain learning style and this doesn’t mesh well with their potential partner. Also, levels of experience can vary quite widely, leading to boredom and less learning for the more advanced person (though usually with benefits for the less advanced).
Some people prefer to be able to take detours and investigate functionality on their own, and are inhibited from doing this in a pair (which is a shame).
Applicability
Pair exercises work extremely well for in-house courses where all those present work for the same company. They usually know each other and are able to pair up easily and quickly.
Not surprisingly, I do not find it so applicable with public courses where only 1 or 2 people per company are present, and the level of preparation and relevant prior knowledge and experience can vary significantly among those attending.
The other keynote at the XPDay conference last December was Mary Poppendieck on the theme of her book Lean Software Development.
“Make More Money”
The title certainly grabbed people’s attention. The key point being that you make more money by increasing your ratio of outputs to inputs.
Productivity in software has had its peaks and troughs in recent years, whereas in manufacturing, productivity is continuing to rise (there was a plateau around 2000/01 but not it’s heading up again). Companies who do well look at their core business processes which are what drives productivity. They then chose where to match industry norms and where to lead (and they pick a few areas to excel at). They focus on end to end improvement. You lead in a decade not in a year so it’s not a short term thing. She referred to the book by James Collins, Good to Great.
Looking at the productivity levers for software:
- What are the processes involved in turning an idea into a product?
- How do you translate customer needs into software? (This isn’t what they ask for it’s what they need!)
- You need to manage your development portfolio (resources and capacity)
- Deploy complete solutions – are you fully invested in the success of your customers?
- Managed the full lifecyle – design for maintainability.
Another large lever is marketing but that wasn’t the subject of the talk.
A key way to improve your productivity is: Do Less Work
Reduce Direct Costs
Reduce the direct cost by providing only what the customer will pay for. A quote from Jim Johnson of the Standish Group: users typically use only 25% of the system – 65% of features are rarely or never used (see Martin Fowler’s writeup of XP2002).
Where do all these extra features come from?
- we ask the customer what they want
- we reward them for thinking of everything (”scope”)
- we penalise them for adding features later (”scope creep”)
She referred to the following book which talks about MMF – Minimum Marketable Feature Set (Mark Denne & Jane Cleland-Huang, Software by Numbers; Low-Risk, High Return Development, Prentice Hall, 2004). This assumes you are deploying early and often.
Reduce Indirect Costs
Streamline your processes to eliminate waste.
Streamline the core processes to provide rapid delivery of value (cost reductions that reduce customer value do not increase productivity – beware of mindless cost cutting!).
The measure of an organisation’s maturity is the speed it can reliably and repeatedly execute key processes. For software this is the speed that customer needs get turned into deployed code.
She referred to the Value Stream Mapping process in her book (see link above), and how to change your processes to remove delays.
Get support people involved in the development and design of a product to ensure that it can be deployed appropriately.
Increase Output (Value)
Do this by shortening the customer feedback loop.
Improve customer productivity – when they win you win. A case study – Dell realised after some customer visits that there was a whole new business in delivering preconfigured PCs. This increased both revenue and customer loyalty.
How can you help your customer?
- Map their value stream
- Extend the value that you offer
Conclusion
Another interesting keynote. Covered a fair amount of stuff from her book, but with some interesting twists that made it very relevant. I also attended her workshop, and some key points from that:
- to get predictable outcomes don’t predict – make decisions based on facts not forecasts
- if you can’t deliver fast, you can’t delay commitment
- speed of software development can have a bad name but is a fundamental competitve advantage
- improve depolyment by testing earlier and making rapid small releases
- to move fast you can’t tell people what to do – they have to know for themselves (”information radiator”)