Extreme Programming for a single developer [closed]

https://softwareengineering.stackexchange.com/questions/219940

01-10-2020
|

Question

I've been working with some basic extreme programming concepts for the last two weeks, for a small scale, for-profit, multiplayer, arcade game. I've spent a week developing user stories and determining requirements to create a release plan. I've also spent a week coding and applying the first iteration plan I came up with. I've identified a few of the obviously useful concepts for a single developer.

Continuous Integration
Never Add Functionality Early
Test Driven Development
Choose a System Metaphor
Use a single Integration Point
Test out all bugs
Constantly refactor
Set a sustainable pace
Simplicity
Frequent Releases

I'm curious if I'm missing anything in particular that might be suited to working with a single developer project?

Also, in this light given the idea of simplicity and test driven development, is it better to use established, feature-rich, ready made platforms?

Or should I work from the ground up, when feasible, to avoid running into the issues presented with rules such as constantly refactoring and never adding functionality early?

Solution

Ultimately, Extreme Programming is about a set of practices and methodologies that lead to improved business value. The best illustration of this that I have found is from http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart

Extreme Programing Enablement

Everything in blue is part of the core of XP.

There are parts of it that are at the outside of it that help enable things within the blue area and are part of XP as a whole, but not critical to it. Note that I am personally not an XP practitioner and I've read a fair amount of criticism of people "almost" following XP that various people have said isn't XP. Lets set that aspect of the dogma of XP aside for a bit and look at what we have.

Realize that one of the first and for most things is to have a commitment to the process from the customer. A key component of XP is the customer involvement. This shows up in a number of the spots such as release planning, small releases, offsite customer evaluation. These are things that your customers will need to subscribe to if you are going to be successful at XP as a solo developer. If they ask instead for a design and then a development period and then testing and such, you won't have the commitment from them to go further.

XP doesn't mean no planning. There are several points in this where planning is part of it - prioritization, user story estimation, iteration planning, and task definition. Even though you are one developer on this, these are things that you will need to work with your customer on delivering.

Points such as collective ownership of the code and pair programming are things that involve more than one. Deciding upon things such as coding standards are much easier, but it doesn't mean you don't have to follow them. Collective code ownership still applies - its just that the ownership is also the next developer - don't write code that is for you and you alone. Note that this is in some degree of conflict with the 'code reveals all intention' that is enabled by pair programming - you don't have that person to check that you are writing maintainable code so documentation of the code is also critical.

Apart from those caveats, many of the XP design principles still apply. Things such as test first design, continuous integration, meetings with the customer, refactoring, YAGNI, spike solutions - those call can be done solo.

Realize that solo XP takes as much or more discipline as regular XP. XP is often considered a high discipline methodology in that it requires people to maintain rigorous adherence to the best practices that it tries to embody. When you don't have a coach or other people to support that discipline needed it can fall away into just a hodgepodge of practices that bear some resemblance to XP.