Agile software development is based on the premise that project planning is frequently overdone, since requirements change often during development, and as a result, large-scale plans are almost always wrong.

There are many good resources out there on topics like agile development and extreme programming, and I’ll provide references to some of my favorites throughout this post. But sometimes a developer works alone, for example on the beginning stages of a pet project, or as the only freelance programmer in a small team of customers. Since the basic implementations of all Agile methos (Scrum, XP, etc.) are designed for teams of 3+ people, standard agile techniques don’t work out-of-the-box and have to be modified. The purpose of this post is to summarize and organize the material I’ve found on how a solo developer can adapt and use these strategies.

This post was and will be changed and improved as I continued to tailor the method to my liking, all in the Agile fashion of “deliver fast and iteratively”.

Personal Extreme Programming: The practices

Many of the 12 core practices of XP can be adapted by solo developers without modification, while some have to be adapted slightly. Here are the core practices and how they can be modified:

  1. The Planning Game

    Decide which features will be of maximum value to the business. If there is no customer yet, you could switch roles and stand in for the customer.

  2. Small Releases

    Aim for early and often releases. This means having only a very simple system in the beginning.

  3. Metaphors

    Strive for a single, consistent, and plausible system of names.

  4. Simple Design

    Use the simplest possible design and don’t worry about future requirements.

  5. Testing

    Write the interface first, then the unit test. Now, implement the module (in the development branch). Test and verify the code before refactoring.

  6. Refactoring

    Refactor in a refactor branch. After the refactored code works, put it into the production branch.

  7. Pair Programming

    This one, unfortunately, has no equivalent when working alone. To modify it, it’s important to understand that the main benefit of pair programming are not to find more bugs early, but to eliminate distractions and improve focus. You can get an approximation of the benefits by practicing increased discipline, focusing hard, blocking distracting websites, and frequently stepping back and looking at your code from a bird’s eye view.

  8. Collective Code Ownership

    This is actually an advantage of solo development. You know the entire codebase and are automatically able to understand and modify every part of it.

  9. Continuous Integration

    This ensures the development line never strays too far from the production code. If you are alone, conflicts are less frequent, though.

  10. 40-Hour Week

    Stop working when you are getting stressed or tired and are no longer productive.

  11. On-site Customer

    The key is to have permanent feedback from your actual customers.

    Initially, you are often your own customer. Later on, your workaround might be to have frequent e-mail exchanges or phone calls.

  12. Coding Standards

    Adhere to a self-imposed coding standard to have a consistent code base.

Phases in PXP

The following figure (source) summarizes the iterative process in PXP:

It makes sense to keep notes (called logs in the figure) during your process and write down how accurate your task planning was, how well you focused, and what could be improved in the next iteration.

  • Requirements: In the beginning, create a document with the functional and non-functional requirements of the system.
  • Planning: Assemble a set of tasks and sub-tasks based on the requirements and estimate their effort. Major design decisions are made here, such as the choice of programming language, framework, etc.
  • Iteration Initialization: Iterations should take 1 to 2 weeks. Select a set of tasks which become the top priority in this iteration.
  • Design: Model the system modules, classes, and functions that will be implemented.
  • Implementation: As before: Write your tests, implement the code, and as soon as it works, refactor it.
  • System Testing: Verify that your solution meets the project requirements.
  • Retrospective: Analyze all data (notes etc.) collected in this iteration. Check how accurate your effort estimations were. Find or analyze proposals for process improvement and adapt if necessary.


To experiment with PXP and refine the method to a tailored solution that works for me, I am applying these tools to a set of programming puzzles called Advent of Code. It is a yearly recurring event in December where the author publishes christmas-themed programming puzzles in an Advent calendar style.

I’ve tried and continuously adapted the PXP method to my personal preferences during December 2017. My solutions started out as simple ad-hoc scripts, but the third day’s puzzle was already tricky enough to require a more professional approach. I thus switched to a test-driven design and went through the basic cycle of “1. write test - 2. code until test passes - 3. refactor existing code”.

Further Resources