I’m an independent software engineer working on a contract basis. I have a process for projects. It’s a relatively lightweight, loosely agile methodology. It attempts to ensure projects run smoothly by building software in a series of short iterations.

Face-to-face or Skype meeting

After an introduction is made, I organise a face-to-face or Skype meeting. I get an overview of the requirements and the context in which the application will sit, the business goals. Clients often have preconceptions about what I’ll do, how long it will take, etc. I like to learn about the project so I can challenge those preconceptions if necessary. For example, if a client asks me to create a blogging tool, I’ll make sure that none of the off-the-shelf tools will do before proceeding. I’m actually pretty vigorous in recommending alternate approaches. My experience is that a lot of stress and heartache can be avoided.

Because I practise agile software development, I encourage clients to find a minimum set of features which can be implemented an iteration lasting up to 2 weeks. This is a useful process. It encourages both me and my clients to think about the business goals first. If those goals can be met without software or with off-the-shelf tools, we can make that decision now.

Specification document

After the initial meeting and a follow-up email or 2, I will produce an iteration specification document. I usually get this to the client within a few days to a week depending on how busy I am. I can rush it through if necessary.

The specification will list the set of user stories (how the app will be used, tasks it will support) and the features required (the actual stuff I’ll build). The feature set will take no more than 2 weeks to develop, test and deploy. Additional features are left for subsequent iterations.

If the client is happy, work begins. Otherwise the spec is revised. The spec is my statement of intention, this is my understanding of what the client wants me to build. I ask my clients to check this carefully. If I’ve got something wrong, it’s time-consuming to fix later. It’s often hard to make spec docs exhaustive and unambiguous and this can lead to disagreements, I try hard to avoid that.

Developing iteratively

The work begins on the first iteration. I will develop the required features and test and deploy the software within the stated time period. During this period communication slows down a bit. Coding requires a really quite extreme level of concentration so I tend to close my email, Skype, etc and put my headphones on.

Only quite minor changes to the spec can be accommodated once an iteration has begun. If changes are frequent, it’s very hard to get up to speed. A car can go much faster on a straight road. The client’s desire to provide new feedback and ideas and the developer’s desire to get the job done are often in competition. The beauty of developing in short iterations is that this competition can be resolved. Ideas can wait a week or 2, in fact they benefit from more consideration, meanwhile the develop can code away undisturbed.

Towards the end of the iteration, the new code is deployed to somewhere where it can be tested by myself, the client and other stakeholders, often a staging site. Bugs are found and fixed. Loose ends are tied up. Finally, the software is put into production. Bug testing and fixing takes from 25-50% of the iteration time. Deployment is generally straightforward, but can still take a few hours, for that reason it’s only done once per iteration.

When an iteration is complete, the process begins again. A face-to-face or Skype meeting allows the client and I to assess what’s been achieved so far. Learning from one iteration goes into the next. A new spec is produced and I get back to work.