Agile programming works for the solo developer

Agile programming, a.k.a., extreme programming (XP), has a lot to offer the lone developer. Learn how agile programming's practices can bring order to solo development efforts.

You may not realize it, but if you’re a software developer who works alone, you may already be using a lot of the concepts behind agile programming, also known as extreme programming, or XP. Of course, certain agile programming practices, such as pair programming, simply don’t apply, but the organic nature of the agile methodology easily lends itself to rapid application development, even for the solo programmer.

I’ll step through the relevant practices of agile programming and how they can facilitate application development in the one-man shop.

Agile programming overview

The agile programming methodology is divided into four activities and deployed with an iterative style. Planning, designing, coding, and testing are all performed in bite-size pieces. These steps are revisited when needed or according to schedule.

When you’re developing alone, it’s easy to just dive in and assume that you’ll be able to handle whatever problems arise. Agile methods can facilitate the process, however, and will actually help you avoid the lag that comes from struggling with a less organized approach.

I’m an independent application developer, as are many in the current economic climate. As of this writing, I’ve got four separate projects. While I can easily manage requirements and progress status for each of these endeavors, I’ve found that the time needed for sourcing, ramp-up, and development is greatly reduced simply by applying a little order to the chaos.

Borrowing relevant agile programming methodologies has worked quite well for these projects. For one thing, agile programming isn’t heavy and doesn’t require an inordinate amount of overhead. Also, every piece of planning is immediately useful, and my clients get a sense of constant contact and the instant gratification of regular updates. The practices defined by agile programming help me put a simple structure behind my work. This lets me focus on getting things done, but it also supplies the environment I need to adapt to and incorporate changes without disrupting progress.

When you’re working alone on a project, planning is easier with the agile methodology than with spiral development or the other methods I’ve worked with. In fact, much of the process comes naturally to the lone-wolf developer. By picking and choosing the pieces that fit, these practices are well suited to working alone.

Agile planning

You may find that you’re already using many of agile programming’s planning practices, although perhaps in a more informal manner. Try tweaking your diligence slightly, and you’ll discover some of agile programming’s tremendous benefits in this area.

User stories

User stories are a way of capturing what I call “the flood.” This is similar to requirements gathering in traditional development methodologies, but it differs in that technical details are omitted and work to be performed is described in plain English, broken out into two- to three-week sections. Each user story is written onto an index card and used to plan releases.

Since one-man projects tend to be small, I generally break the user stories into shorter duration blocks. Of course, this goes against the rules of the “planning game” and ultimately quickens the iterative rhythm; however, the same basic principles apply.

Releases

A release consists of user stories grouped together based on dependencies and business need. Agile programming releases are not partial deployments but rather represent completed, logically grouped portions of functionality. Scope or duration can determine a release, and functionality is chosen by common sense and priority.

As with team projects, keep releases short. Each release comprises several iterations and is largely determined at the beginning of the project. Organize releases by grouping the user story index cards together. This allows you to keep the customer satisfied with frequent deployments, and it helps keep the focus on the big picture.

Just-in-time planning

Once you have an idea of the releases, determine your iteration length. An iteration should be one to three weeks in length, and there should be three or four iterations per release. Even with shortened user stories, I’ve found that sticking to the low end of this guideline works on lone projects, as long as I make sure that all iterations are about the same length. Otherwise, it’s too easy to break away from the agile model.

Define iterations by selecting the most important user stories and breaking them down into programming tasks. Involve your client in deciding what task has the highest priority, and always plan to complete it first.

Iteration planning should be done at the start of that iteration and not before. This may seem somewhat shortsighted, but it keeps you focused. Discrepancies will be resolved in future iterations.

Designing the solution

Designing your solution with the agile methodology is simple. It’s spread out over the course of development, rather than being completed up front.

Class cards

Create index cards representing objects and classes. Use the cards as you would boxes on a diagram to demonstrate the objects’ relationships. Keep it simple, and refine the layout with additional detail when planning an iteration.

Refactoring

As you move through the project, take time to clean up your code and consolidate functionality. This is called refactoring, and it allows the system architecture to develop logically and organically. Every iteration should include time for restructuring; the class cards can show where it may be necessary.

Spike solution

When you encounter a tough problem that lacks an immediately apparent solution, create a spike solution. This is where you try out different approaches in code to make the correct solution more apparent. This happens all the time in independent development, and it may not require the level of formality that agile programming calls for.

Other design principles apply as well, but many are somewhat inherent when the team is a single person. For example, it’s a good idea to name objects and other system elements consistently, but as an individual, you probably don’t need to formally create a metaphor.

Coding guidelines

Much of the coding guidelines for agile programming refer to management of teams, but a few concepts are worth adopting.

Client contact

Frequent contact with the client is crucial for the deferred planning of this methodology. Not only does frequent contact help clarify details and prioritize tasks, but it’s also a great management tool when you work alone. It gives the client confidence in your ability to deliver and keeps the client abreast of your progress.

Testing framework

Create unit tests before writing code. This might seem a little like overkill for small projects, but it actually keeps the scope in focus and limits development to the requirements. Code enhancements and additions must be completed in a separate iteration, facilitating quality assurance.

Even though it’s a good idea to create a testing framework, less formality is required for one-man projects. Since I usually wind up writing code and interfaces, I use preliminary interfaces with debug flags as my test mechanism for back-end functionality. Although this isn’t as stringent or long-lasting as the agile methodology’s preferred practice, I’m comfortable that it meets my needs.

As extreme programming enthusiasts are quick to point out, the process is designed to be modified to fit your needs and changed when it isn’t working.

Test before moving on

Once you’ve completed coding a particular piece of functionality, make sure it works before moving on. This is one of the ideas behind creating unit tests up front. When the relevant code has passed the unit test, it can be integrated. After completing all tasks for a user story, apply functional tests to ensure all requirements are met. When you find serious bugs, modify your testing to check for them after they’ve been fixed.

When you’re working alone, this is pretty much the natural progression of testing code anyway. By creating formal tests before writing code, it’s evident whether a piece of functionality works or not.

Bringing structure to the soloist

These are some of the principles of agile programming that apply to solo development. I picked up these habits on a recent project as an experiment to see if I noticed any improved efficiency. It took about a month to really get into the habit of not solving problems before their time and being diligent about refactoring, but my productivity increased once I got a rhythm going.

I really like the way the client took an active role through continual contact, and forcing myself to create test cases before writing the code facilitated development. If you’re a single developer, agile programming can give structure to your process.