Small Projects are no Excuse for Sloppy Process

In the past few years I have been involved in a few small development projects. By small I mean a project with two or maybe three developers and a timeframe of four to eight weeks. Some of the projects have been very successful and others have been more troubled.

In retrospect I found that the in the more successful projects we applied a more strict agile process. The most troubled projects were those that were run in a sloppier fashion.

In a small project with a tight budget it is essential that you:

  • Show continuous progress
  • Can respond to change quickly
  • Don’t waste time on things that don’t add value
  • Reduce defects

To be successful in small projects, in my experience, you should at least do the following:

  • Have a product backlog
  • Each product backlog item should be small enough to be completed in one day
  • Use a task board
  • Demonstrate your software one a week
  • Do test-driven development
  • Practice Continuous Integration
  • Automate build and deployment
  • Have retrospectives regularly
  • Daily stand-up meetings together with the customer
  • If you need estimates, use T-shirt sizes (S, M, L)
  • Pair-program as much as you can

A consequence of the last point is that you should never be alone no matter how small the project is.

What can be left out?

In my experience you can safely in most cases skip the following practices:

  • Break down of features into tasks
  • Detailed estimation
  • Burn-down charts
  • Velocity tracking

Test-Driven Developers have more fun

I started using TDD a couple of months ago and what strikes me now is how much more fun it is to develop in this radically new way. There are several reasons for this.

A common frustration when developing in the traditional way is that the progress is not immediately visible. This is particularly true in larger projects. You write a lot of code before you get something that is working and can be demonstrated. With TDD, every new passing test is a clear sign of a small step forward.

Another common cause for frustration and dissatisfaction for a professional developer is that many times you are not confident that your code is working as expected. If you apply TDD, allmost 100% of your code will be covered by tests and that will make you confident that the code is doing the right thing.

In the past I have sometimes suffered from “code writer’s block” when I’m trying so hard to get the design right from the beginning that I couldn’t produce any code at all. With TDD you don’t have to get it right from the start. The tests allows you to try out different designs and easily refactor the code without breaking it.

Every now and then I try to write some code for a hobby project, but I rarely got more than an hour or two free for coding at home. A TDD roundtrip of “red – green – refactor” typically takes less than two hours to complete, which means that even though I have very limited time I can still make som progress by adding at least one passing test every time I get a chance to write some code at home.

Conclusion

By applying TDD you will get greater job satisfaction as a developer. You will get feedback serveral times a day that you are making progress. You will be more confident that the code you are delivering is working as expected and you will find it easier to experiment with the design, thus giving you more freedom.

Feedback, confidence and freedom are factors that will make you enjoy your profession even more. Don’t miss an oppurtunity to have more fun at work and with your hobby projects – jump on the TDD bandwagon now!!