Extreme Programming For One

Scenario

A lone software developer is working on several small to medium scale projects. He needs to increase his productivity and resilience. While his management are amicable and approachable, they tend to frown on "over-designing" a system, since it is "liable to change in the future anyway".

This programmer has been using patterns with Java for a while, but he has no techie colleagues to pair with, and very limited contact with the end users. Requirements tend to "appear" at any time. The management seem to accept that and the resultant geometric increase in effort needed to add to and maintain the design/code.

Can XP help?

See also: ExtremeProgrammingChallenge (source of this discussion), ExtremeHacking (controversial alternate name for this?)

I hope you all don't mind this rather personal scenario (I admit that I am the programmer in question), but I think that any answers may be applicable to a wide range of loners and lurkers whose interest is piqued by XP. -- DavidMcNicol

We'll be glad to help! Here's a first cut. Other XP masters and observers, please pitch in!

XP does not believe that there is a "resultant geometric increase in effort" as a result of change. XP is built to thrive on change. Requirements appear and change at any time. Here's a short summary of how that happens.

We plan the entire project based on UserStories, using the ReleasePlan to describe the overall plan. We plan our work in (three-week) iterations, using an IterationPlan to say what we're going to do. We build our code using PairProgramming (this one is tricky for one person). The AcceptanceTests, of course, tell us whether we're done.

We DoTheSimplestThingThatCouldPossiblyWork. This means that we do not build for needs we might have in the future: we accept that we can't guess, so we don't waste time doing it.

To allow for future change, we RefactorMercilessly. We keep the code as simple as possible, which means that after we put in a simplest solution, we refactor the code to do everything OnceAndOnlyOnce, which is a simple description of what you get when behavior is all on the right objects and the code is in the simplest rest state for what it does.

We ensure that refactoring changes and new features work by RelentlessTesting of each class with UnitTests and of the entire system in operation using AcceptanceTests. This lets us be sure that the changes we make don't break things that already work, and that our new functionality works as well.

We keep the system working all the time via ContinuousIntegration (see also ContinuousIntegrationRelentlessTesting for some further discussion of how these work together).

Wow. Remind me to save this description. Anyway, if I were working alone I could do all these things (except pair programming). Maybe that one could be substituted with some kind of review process with peers on the web or in the community.

The pair programming partner doesn't have to be a programmer. You don't need to be an expert to say, "Did you run the test?" every five seconds or so. Kids could work well as programming partners.

Here's how I'd try to work:

Get small, simple descriptions, on cards, of the known requirements. From those, select, with whatever guidance you can get, the next feature to be added. Think of the simplest way to put it in. Write UnitTests to see whether it works. (Usually it doesn't.) Write the code in the simplest possible way. Run the tests, make it work. Then refactor the code to keep the system at its overall simplest. Report the card as done. Go on to the next.

The keys would be simplicity and testing. The keys are always simplicity and testing. -- RonJeffries

I can't help thinking that the above includes a bit of sloganizing. Notice the original poster mentioned very little end-user contact. The reply didn't seem to address that (even though the essence of XP is said to be listening). Sure I would say that DoTheSimplestThingThatCouldPossiblyWork essentially does address the situation (if it's similar to the ones I've seen). But the whole article isn't addressing the question very directly. I think another simple XP answer to the original question might have been simply "relax and learn to enjoy programs designed only as much as is appropriate for the moment."

I suspect that complex design methodologies are something of a siren song to many programmers - where XP seems involve a sensible method of designing only to the degree you've coded, discovered what to do, etc.. Again DoTheSimplestThingThatCouldPossiblyWork. There, that is the part you want.

But in general, I'd also say meet your users. Even if you have sneak and do it. It gives you an idea where things will ultimately go.

I've had assignments where not only is an "exponential increase in effort" accepted, it was so expected that if it didn't happen, something was considered wrong. My war story involved a situation where I knew the user requirements, designed the solution to these early, then had to duck and dodge changing management requirements - which I happened to know wouldn't last.

I think a bare-bones design philosophy - architecting only as much as needed designing at the moment while secretly figuring what they really wanted - allowed me to do something that amazed people ultimately - actually completing the project before it was due.

-- JoeSolbrig?

I have been typing in responses here for the past half-hour, and things have been clicking into place (thanks, Ron). I think my main worry about XP stems from my programming environment: jdk, Unix and vi. Even though I can see the value of XP, constantly refactoring from the command line seems like a daunting task. -- DavidMcNicol

On your environment: try vim and exuberant-ctags from http://www.vim.org . This should make all that refactoring a lot easier to do - fun even. Vim is free, entirely backwards-compatible with vi, and vastly more powerful. Exuberant-ctags gives you the ability to flit from use to declaration without ever leaving the editor or doing a grep. Very good for flow, much better than some clunky IDE. -- PeterMerel

I use JDK, Unix, and wily (see the AcmeProgrammingEnvironment), and I have found ExtremeProgramming (for one) to be a real blast. Wily works well with the way the JDK prints out exceptions - the "should" and "shouldEqual" methods of my testing framework throw a ShouldButDid? exception when the test fails; the point the test failed is then just a click away. For the first time in a long time, I feel like I am writing code with confidence that it will actually work....

When I'm by myself, I don't separate UserStorys and EngineeringTasks (I generally work as both Business and Development when I program alone). I keep a ToDoList, either on a card or in a workspace. Every time I think of something else I might like to do, I add it to the list. The list grows and shrinks, but tends to grow over time.

After a while, I know I am getting close to a useful release-able system, so I draw a line. I go through the list and put items below the line that don't need to be in the release. When I create new items, I decide whether they go above the line or below. When there is nothing above the line, I'm ready to release.

It is important for me to always be working towards an item on the list. If I am just refactoring for fun, I stop myself and ask whether I am contributing to an item. If not, I set myself a time limit and play.

The real question is how much less than XP you can do if you are alone. I think the planning stuff scales down nicely. You have to test and refactor. You can't pair. What else less could you do? -- KentBeck

Another trick - if you keep the list on a card, when the card fills up you copy all the undone items to a new card. If there is something little, I tend to just do it rather than copy it. This keeps the little stuff from piling up. -- kb

I do something similar, but I keep the stuff in text files because otherwise I think I'd lose it. I use the marker "XXX", which comes up in a nice egg-yellow under vim, to indicate little things that need to be nailed down as I go; I also keep a ToDo section in major class headers and delete items as they get done. I confess I haven't tried to share such ToDo lists with other developers - they're more notes to myself than any sort of documentation for others to see. Probably a sign of insecurity. -- PeterMerel

Especially when writing open source, the tag "XXX" tends to have problems. I prefer using "FARKLE" or "TODO". The problem with XXX is, in today's environment, your source code can be flagged as "unsafe for children" by automatic site blockers...

Of course, that could be a good thing, depending on your current view of the programming world...

In most vim configurations, "TODO" should light up just as nicely as "XXX". That's what I use for that purpose.

Note that Kent is working as both business and development when working alone, and he is extremely experienced at working alone. I'd strongly advise a normal human to be a bit more orderly:

  1. Break down your UserStorys (requirements) into EngineeringTasks, which will help you focus on how little you can do, and will help you not think about the future.
  2. Always have a releasable system, not just when you get close to some major increment of function. To accomplish this, work in small bites, release often, and keep all your tests running at 100% all the time. Then when the PTB want a release, they can always have your best.

I don't agree that the question is how much less you can do. I think the question is how much of XP's benefit can you get, and what's the most effective way to get it.

Certainly you don't need to hold an IterationPlanning meeting with yourself ... but it would be valuable to identify your tasks and estimates and track your performance against estimates. This will help you identify things that slow you down, time-wasters, etc.

You may or may not need a CommitmentSchedule. Depends whether you need to communicate with the boss what you're going to work on, and how long it will take. If they want to set and change your priorities often, having the stories on cards will be a good way to communicate and track.

All the coding rules, except Pairing, apply. All the testing applies, more than ever because you don't have a partner to catch you when you stumble.

Ask not how little you can do ... ask how you can best benefit. -- RonJeffries

I've only done solo XP where I was Business and Development. In the challenge above, Business is somebody else. In this case, you certainly have to make the UserStory's explicit, add the estimates, and get Business to give you priorities. The lack of contact with real users bothers me. Take one to lunch. Sneak out and watch one. Info straight from the source is vastly superior.

Re: releasable system. You don't need ContinuousIntegration, or rather you get it for free. The test cases have to run all the time, of course. -- kb

I'd want ENVY if I could afford it, and would use it with versioning/release. That way I could change a bunch of classes, decide I was loony, back it all out with impunity. Agree I don't need ContinuousIntegration, but I would retain the distinction between code in process and code released. -- rj

Ok, I'm beginning to get this. I can see how XP can be used for integrating new functionality into an existing framework, but how does an extreme programmer write a framework from the ground up? I can see how to get requirements down as user stories, but won't the first user story require a huge number of engineering tasks in order to construct the framework?

I'm sure I'm missing something here (possibly a decade of programming experience..) -- DavidMcNicol

Umm, how about just don't construct the framework? i.e. YouArentGoingToNeedIt. Just make a SpikeSolution and start adding to it and refactoring. The "framework" often just pops out at you as a result of refactoring.

There seem to be several things going on here, all grouped together as ExtremeProgramming, and bandied about as one thing. Please correct me if I'm wrong, but I'd like to take a shot at this, because I think it might make XP easier for newbies to understand.

There seem to be (at least) two axes of information in discussion about XP, one of which became clear(er) to me while reading this page, which is why I'm posting my comment here. The axes I see are Coding vs Process and Practices vs Aphorisms. Granted, there is some overlap and considerable grey area between these, but I think that grouping them all together does a disservice, at least to newcomers, because it makes XP look more complicated than it is (or than it seems to me).

Here is my first take on dividing XP into manageable categories:

Note that this division is dependent on context. Outside of the ExtremeProgrammingForOne context I would put PairProgramming and ContinuousIntegration under coding practices rather than process practices. Maybe what I'm calling process here is just what is difficult or redundant when doing XP for one?

The point I'm trying to make is that the aphorisms are nice things to keep in mind, tack up on the wall, etc., but the practices seem to be core things you do when you do XP. Conversely, the coding part of XP seems to be accessible to anyone, alone or in a team, with or without management support, while the process part seems to require more cooperation from the business/team.

Thoughts, criticism?

-- DetheElza

See SpikeSolution. On C3, we had enough user stories to know what payroll was, and we had defined our "metaphor", which others might call architecture. It's an analogue to an assembly line: hours and money are Parts, kept in Bins, processed at Stations.

We built a payroll system in one week. It didn't do much: just paid one guy his base pay (entitlement), took 27% federal income tax (deduction). But it had a Person, with a Profile, Parts in Bins, processed by Stations. Even printed a check as I recall.

There probably isn't a line of that code left in the system, but we just evolved it from that Spike to over 2,000 classes. Our fingers never left our hands! -- RonJeffries

I've tried working alone several times, and I usually found that my natural practices square pretty much with the XP practices. But not being able to pair is a really serious drawback. It affects the quality of my work, because it removes the 'continuous review' aspect of XP. And without a sounding-board I work veeerrryyyy sloooooowlyyyy - because I get no feedback on which of my ideas are good or bad. Cutting tasks into tiny pieces helps; so does not thinking ahead (I often get into abstract loops, or caught on the horns of a dilemma).

Can anyone suggest other/new practices for ExtremeProgrammingForOne that might reinstate the quality and speed benefits of pairing? -- KevinRutherford

This is something I'm trying to get a handle on for JeraWorks. Some thing I've thought of thus far:

-- JohnBrewer

As strange as it may sound, I have found that frequent interruptions help achieve some of the benefits of pairing (which is what happens when you program at home with two little boys running around). Specifically, they prevent me from wasting too much time on a single task (instead of trying other approaches once the first approach turns out not to be that simple), they allow me to "lean backwards" and see the bigger picture (especially the holes in it that I forgot to fill), and they provide an opportunity to think without being bothered with the mechanics of keyboard and mouse - my best ideas come during interruptions.

-- YonatSharon

If kids will work as a programming partner, how about that silly paperclip? Give it something useful to do beyond consuming spare cpu cycles... that might actually make me wish Linux had a paperclip! I'm in the same boat with regard to not having a pair. The fellow that introduced me to XP is assigned to customer support and not available for pair programming on my current project. -- JoiEllis

It's already been done, though not particularly usefully. Look at Vigor, based on nvi, and written by Joel Holveck. It's based on the UserFriendly cartoons from 4 January 2000 to 14 January 2000, and uses Tcl/Tk to provide a snide paperclip companion. It's available at http://vigor.sourceforge.net/. Here's the screen shot page: http://vigor.sourceforge.net/screenshots/. -- EricJablow

See also ExtremeHacking

A virtual pair programming partner for eclipse is available http://www.azzurri.jp/en/software/soloprogramming/index.jsp

-- BastianBowe?

Something that struck me as missing from the list above is early, small, and frequent release. For me, GetItDone? is the fuel that drives a project.

-- EricSmith

I'm currently doing a project solo, trying out some of the practices of XP. The team at my primary client site is slowly moving towards XP, not so much in enemy territory as on unsettled ground. In both, the concepts are definitely helping out.

For the solo project, I'm using C++ and CVS on BeOS. The team is on Perl plus shell and ClearCase on HP-UX. I prefer the solo project, actually, since I can make more progress faster. Still looking around to see whether I can pair with someone (here in northern San Jose CA). Worst problem on both is UnitTest right now, which is getting beaten back into shape as the hours fly by. Thankfully the team isn't getting itself into ExtremeProgrammingInEnemyTerritory, more like XP on unsettled ground.

XP for one is, in my opinion, a much saner way to develop solo than anything else I've come across. -- JosephBeckenbach

I'm going XP solo on a web based HR system: SystemForManagementOfCasualStaff that is also functioning as a graduate project. I'm noticing a lot of situations where PairProgramming would be more than helpful, but on the whole XP solo works for me. The hardest thing for me so far has been to keep a working set of AcceptanceTests with a Web interface, i.e. WebTesting. CaptureAndCompare? produces very rigid test suites that refuse to grow naturally with development, but I haven't found a good alternative yet. -- GarethCronin

There is a story about XP for one by Bryan Dollery at http://groups.yahoo.com/group/extremeprogramming/message/38001

When working alone I usually get out of my path and take too much time in one phase. I found SandglassProgramming helpful for self-discipline.

By yourself, you don't have as much feedback as when pair programming. Especially when you are practising TDD it's too bad. You want to learn TDD effectively. Try DoItAgainToLearn. Try TDD on the same problem a dozen times - I bet you will be really amazed at the result and will experience a kind of paradigm shift.

-- JuneKim

I have an idea for a new practice to help solo domain programmers: StartWithSeeds

For me it is very hard to use the SimplestThing idea. -- KarlNeuhold

Train someone around you to say something from this following list at random intervals. Perhaps even find software to do this.

There are others... you get the idea. -- JbRainsberger

I am a Microsoft Access and VB programmer.

I love the philosophy of extreme programming but the testing phase is one concept that I can't seem to get a handle on.

For instance: Lets say you are developing a simple index card database application. Within this application you might have some simple functions such as Go To First Card, Go To Next Card, Go To Last etc. You might also have implemented a simple calculation or two that is to be performed each time a card is brought up for viewing. How does one go about writing test for this application? Do I simply test each of the coded functions and see if it returns the expected results?

I could probably learn a lot by seeing just one complete Extreme Programming environment, preferably in MS Access or VB, that includes the application and the test. Are there any examples online?

-- Ted

Start by reading TestDrivenDevelopment. It's not VB, but maybe you'll find TestingFirst instructive.

I am new to XP, and was going through the documentation on the extremeprogramming.org site. I must say that I am not at all convinced that this XP DOES work? Hang on don't shoot me..... I know I am naive but I have my points. Let me put'em:

  1. Going through the literature available for XP on the net it seems, that XP assumes that the world is IDEAL i.e. 2+2 = 4. Well if you know what I am talking of the software development has matured over all these years but still has the uncertainty of English weather... nothing is ideal here. On the contrary, I would say that XP is refreshingly honest about the fact that the world is not ideal, requirements are ill-defined, customers change their minds, and any sane development process must acknowledge these facts and be robust in this kind of situation. That's why it advocates short iterations and a tight feedback loop involving the customer.
  2. Didn't seem to find anyone advocating XP to be used for large projects or teams which I guess is a major share of all the projects/revenues for IT companies. Did you find anyone saying that it didn't work in that situation? What makes you think that it doesn't scale?
  3. The concept of pair programming appeals, but then it assumes that all members of the team are equally skilled and the best pals one can imagine.... Well what about the dynamics of skill levels in the team, their inter-personal relationship...all these factors I am sure contribute to the productivity and in this case would either slowdown the iteration and/or stop any meaningful work to be done. The skill levels tend to work themselves out; everybody learns something from their partners. / Another response: Agreed on the skill levels: one developer may have excellent knowledge of the problem domain but have a lower skill level than their partner, and in that situation both benefit from pairing. The page on PairProgramming and those that it link to have more information, but I've not seen any prose account of pairing which compares with the eye-opening experience of actually doing it. It's really very different from coding alone, in ways that seem hard to verbalise.
  4. The concept of "YAGNI" is absolutely hilarious to me in this connected world and inter-locked world. XP says do what is required for the current job. Don't think about the future things. How can you do that in a software development project. Doesn't one need to know the overall scheme of things so that the developer can plan the best possible and optimal solution to resolve all the connected things. Let me take an example, If I write a EJB which achieve a Business function. Lets say in the current iteration I have a story for which this EJB needs to have a method A exposed to the client. Lets say this method accepts 2 args and returns a String. I do this work as XP tells me to focus on the current issues at hand and forget about future. Everything goes fine. The second iteration comes along and this time around the User Story requires a function on the lines similar to method A. Now the developer has 2 options, either modify the exiting method A to accommodate this new requirement or write another method. Both these options are dangerous as for the first one you need to re-test your earlier story which means added and unaccounted for time, and for the second you are just cluttering the code. That's why the tests are automated -- it only takes a few seconds to re-test method A after modification. Or, you can CloneAndModify? to make a new method B that does what's needed (with tests first, of course), then refactor out the common bits with the testing support. See TestDrivenDevelopment.
Well one can say keep all the eggs in one basket but knowing Business requirements I think we can say that's impossible....

So guys help me understand XP better, it's not that I am against it or so... how can I be... I've just known it for a few days... it's just I am not able to realize its full benefits.....

-- CZAR

One thing mentioned on various extreme programming sites (www.extremeprogramming.org) is that ExtremeProgrammingMethodologyMayAlsoBeIterarive?. In short the idea is to apply extreme programming practices iteratively as they would best help the current problem at hand.

For example if FeatureBlowup? is a current challenge then perform the XP principle of PrioritizeFeaturesByImportance? and only work on the topmost important feature for the next ExtremeProgrammingIteration? (sometimes also referred to as the "Scrum").

It was mentioned one can't have a StandupMeeting by one's self but without an ExtremeProgrammingHeartbeat a project is dead thus a suitable analogue must be found. Such a possible analogue follows: While waiting for the tea water to boil (and then steep after pouring), or some other hands-free but otherwise idle waiting time daily activity of short but predictable duration, use a blank page and a pencil to write whatever comes to mind about progress so far or problems encountered with the project at hand. It is preferable to do this on a daily activity of known duration otherwise one may SpendTooMuchTimePlanning?. The StandupMeeting is stand-up for reason -- to keep it short. A regular StandupMeeting is a staple aspect of the very important ExtremeProgrammingHeartbeat, without which, an XP project can be considered dead. The ExtremeProgrammingHeartbeat should be added to DetheElza's process list above.

-- Gau

See SoloXpProjects, LiterateProgrammingIdeas LoneDeveloperProjectManagement

CategoryExtremeProgramming

EditText of this page (last edited April 3, 2014) or FindPage with title or text search