SAD - Solitary Agile Developer

Part 1

All this talk about Agile Development has the software industry in flux. It seems like the word Agile is thrown in front of just about every new buzzword in software. Yet one theme remains constant throughout, that most "teams" who use Agile methodologies are exactly that... a team, more than one person working collaboratively with pair programming and the like. But what of the solo developer? Are we to just keep on using the waterfall? Can we not be "Agile?" Of course not...

And thus begins my exploration into what it means to be a solo developer in an Agile world. I believe that solo development is much different than pair or team development. There are extra precautions that you have to take when coding alone that you simply don't have to worry about in a team setting. What do you do when there is no QA team to try and break your code? How can you ensure that your product is just as bug-free and robust as the enterprise package built by 10 developers?

To begin with, TDD must play a key role, as it does in many Agile methodologies. TDD offers many benefits to the lone coder:

• Code with Confidence - All refactoring can be done with confidence, knowing that changes aren't making waves elsewhere in the code.


• Simple Design - The "code only what you need" nature of TDD lends itself to a minimalist design which is far easier to maintain over a long period of time.


• Focus on Requirements - Writing tests first allows the lone coder to ponder what it is the software does, not how it does it.
  

But TDD is only one aspect of the SAD life. There are many other things to consider when developing code in an agile way, all by your lonesome. Tools must play a bigger role in the SAD life. Lone coders must rely on tools for various aspects of the development process. But wait a sec, the first principle of the agile manifesto says "Individuals and interactions over processes and tools." So does that mean we are breaking the cardinal rule? Well, not necessarily. While the level of focus on tools is increasing its still not "as" important as the individual (i.e. you). Alas, the individual still presides over the tools. This leads me to that pesky interactions piece of the equation.

In my experience as a developer, I have found that a constant, uninhibited dialogue with the customer leads to highly valuable software. The reason for this is simple, when the customer feels open and free to communicate with the developer, the developer will keep this person in mind while implementing the product. As the iterations progress, the developer will build a link with the customer that helps them see things from the users perspective.

In Part 2 I will continue this exploration in what it means to be SAD.