12

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?

Kody Manharth
  • 264
  • 2
  • 12
  • 5
    Elsesite, on c2.com (a site that was created early for some discussion of agile (and specifically XP) concepts) - [Extreme Programming For One](http://c2.com/cgi/wiki?ExtremeProgrammingForOne) –  Nov 30 '13 at 20:12
  • That's an amazing resource, thank you. I particularly like the idea of the XP Pledge of Allegiance. – Kody Manharth Nov 30 '13 at 20:24
  • If you read carefully, you'll find names such as [Ron Jeffries](http://en.wikipedia.org/wiki/Ron_Jeffries) and Kent Beck commenting... and well, it *is* [Ward's Wiki](http://c2.com/cgi/wiki?WardsWiki). –  Nov 30 '13 at 21:07
  • So it's written by the creators of the paradigm, that's fantastic. Don't know how I hadn't stumbled across it yet. I'd been using [www.extremeprogramming.org](http://www.extremeprogramming.org) – Kody Manharth Nov 30 '13 at 21:10
  • 2
    There isn't a single bullet in your question that is mandatory for successful software development. The real question is, which ones do you actually need? – Robert Harvey Nov 30 '13 at 21:24
  • This is true, but having a very large list of stories to work with the ones I've been focusing on refactoring, TDD, pacing, and not developing ahead of myself. I assume the ones I'm using at any given time are dependent on the stage of development I'm at. I'm looking at it more as a tool bag than a set of hard set rules. – Kody Manharth Nov 30 '13 at 21:32
  • I'm pretty sure you have everything on your list that will make a successful project (assuming you have purposefully left out source control as it isn't necessarily part of XP). I am however pleased to see a single person project using a paradigm like Extreme Programming; these development methodologies are not only useful for team scenarios! – Richard Dec 03 '13 at 20:32
  • **Grab your laptop, jump out of a plane, don't pull the chute until your code compiles.** Sounds pretty extreme to me! –  Dec 04 '13 at 05:45
  • Kody - IMHO "Test driven development" is the single most important. I think that single mantra encourages all the other issues. –  Dec 04 '13 at 01:32

1 Answers1

6

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.

Related reading:

I'd like to pull out a quote from the first of the c2 links:

Noted Perl Language luminary, and mad scientist, Damian Conway believes that Extreme Programming is actually a misnomer. Since it embodies many of the good programming practises that programmers are taught but almost certainly ignore, he believes that it should really have been called Ultra Conservative Programming

  • Enlightening, to say the least. Currently I'm dealing with issues in terms of TDD, in Flash using Starling. I'm using FlexUnit, and it does not have the ability to handle graphical testing as it is headless. Would it be appropriate in cases like this to simply delegate these tests to manual checks (e.g. is the test for the logo centered on the screen.) Would this be considered integration testing? (i.e. does the Splash screen module work with Flash's stage module properly?) Should I use a mocking framework to simulate the required situation? Can tests be purely ethereal constructs? – Kody Manharth Dec 04 '13 at 12:02