Extreme Programming For One Extreme Programming For OneA 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?
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 FunctionalTests, 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 FunctionalTests. 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
That URL isn't responding at the moment, but you can try http://www.math.fu-berlin.de/~guckes/vim/ instead. -- DavidMcNicol
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:
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
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:
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:
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 screenshot 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 FunctionalTests 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 pairprogramming. Especially when you are practicing 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
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?
Thank you
Ted
tcalbaz@yahoo.com
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:
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.....
Thanks
CZAR
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006