SAD - Solitary Agile Develop(er|ment)

Part 2

Interactions

In SAD there are two different types of interactions. The first is the interaction between you and the customer(s). The second is an interaction with yourself. This may seem a bit strange at first, but once you set down a few ground rules you will begin to find methods and strategies which will keep you on top of your game. Back in September I saw a presentation on Agile Database Design by Scott Ambler. One of the things I found interesting which he noted is that "Programming is like Swimming, its dangerous to do it alone." But does that mean you should not be prepared if you find yourself in the middle of a lake?

I think the reason that Scott says this is because more often than not, the lone coder will not consider things such as reusability, maintenence, best practices, or coding standards when they code. They often just bang out the app with the thought that they will be the only one who will have to work on their code, and thus they can deal with any problems that may arise. Yet how many of us out there look at code we wrote 1 or 2 years ago and think "what the hell was I doing?" So to think about reuability and maintenence you are really only helping yourself in the long term.

SAD requires the developer to swim extra hard. In order to keep their head above water, they will not sacrifice the quality of thier code. The lone coder will avoid hacks and shortcuts just because nobody will notice.

In terms of interactions with the customer, this is one place where SAD will diverge from the Scrum method. Where scrum says only to interact with the customer through the Scrum master as a gateway, in SAD you are the Scrum master and the developer all in one. Interact with the customer as much as possible. There should ALWAYS be an open line of communication between you and the customer. They should feel free to communicate requirements to you and you should feel free to ask questions of them. Interuptions will only cause you to question the requirements as you understand them. This will lead you to constantly reevaluate your code and your design. In addition, the interuptions could keep you from going down any rabbit holes.

But just because you are working on one application alone, does not mean you are alone in the world. The web is full of blogs and sites where people are posting their ideas and best practices about software development and the tools and methodologies they use. Any good developer will be on top of the latest trends and technologies in the same way that a good accountant keeps up with all the tax codes. Information is out there to be consumed.

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.