Blog

Harri
Lammi

25 / 1 / 2010

No Comments 

How To Deliver Software In 7 Days

Prototyping is a fun process. You get to try out new things and you don’t need to worry about production-ready code, automated tests and other routines that are not “creative”. Usually prototyping is not time critical either. You’re not expected to have every bell and whistle ready when the project ends. For a developer it means good times, like somebody is feeding you ice cream with a scoop.

But what if we change the rules a little bit. What if you have to deliver in seven days within a budget, the prototype must work and you need to do this every two weeks. Can prototyping still be fun?

Since spring 2009 we have been working with mobile and web prototypes here in Leonidas. In our case rapid prototyping means a fixed price seven day software project. Two days are reserved for understanding the customer’s needs, designing the prototype and holding the start/demo shops. Five days are dedicated for development.

Over the next few weeks I will be writing a series of posts of the lessons we have learned. This first post is about preparation. The difference between rapid prototyping and a traditional software project is the very strict deadline. Rapid prototyping is like the Cooper test: run as far as possible within 12 minutes. Those runners who have prepared well run the longest. For developers good preparation equals more features done.

Lesson #1: Understand the project goal

The customer has ordered the prototype for a reason. Usually they need a prototype to show to their organization or to their own customers. Or their developers are busy working and they need somebody to build them a walking skeleton for the next project.

Understanding the customer’s needs helps us develop the prototype. If the prototype is used for demos, the visual stuff is more important than the robust form validation we could spend hours working on. So instead of coding everything, you can describe functionality with pictures and enhance the user experience with AJAX.

If the customer needs a walking skeleton, you can spend more time on making your code readable and documenting how the prototype can be developed further.

As the bottom line, understanding the goal helps you to decide where to focus your efforts.

Lesson #2: Prepare yourself for the technical challenges.

Time is our most important asset and we need to spend it carefully. During the development phase it’s better to spend time on customer’s needs rather than learning Rails’ nested forms.

Try to get as much details as possible about the project before it begins. We usually get some information from our customer before the start shop, so there’s time to think about the implementation. If there’s an unfamiliar technical area, there’s still time to study it before the project.

Lesson #3: Check your development environment.

Installing the SDK, configuring the demo server or matching your tools with your co-worker’s environment are issues that require only a little time if everything goes smoothly. If something goes wrong and you use more hours to solve the problem, you have spent a part of your most valuable asset.

It’s better to be ready before the project starts. Create the code repository, create user groups, configure the demo server, prepare the project wiki. Doing these beforehand can save you a half day’s work.

Lesson #4: Have your project management tools ready.

In our prototyping projects we need to handle requirements and test results. The concept designers have an ongoing discussion with the developers how the prototype should work. These requirements are written to the task backlog with priority and developer’s time estimation. Whenever testers find bugs they also write down their findings to the backlog. Developers pick tasks based on the priorization and mark them done when finished.

We use a shared spreadsheet as our task backlog. It’s fast, easy to use and developed for our needs. After trying some online project management tools and a task board we decided to stick with the spreadsheet since it worked best for us. The backlog spreadsheet is improved between projects and that would be quite impossible if we used a commercial tool.

The lesson here is to have the backlog or any other tools you are using ready before the project starts. Make sure the tool is really helping your team.

Lesson #5: Find reusable code.

If you make a list of the common functionality web applications have, you would list things like authentication, authorization and lost password mailers. From prototyping view these are nice-to-have items (see Lesson #1), so you shouldn’t waste time on them. But on the other hand, you would impress your customer by delivering these features.

One solution is to have these features available in your project skeleton (check out Ryan Bates’ excellent Railscast). Knowing the features are tested and ready to go, you can concentrate on the items your customer really needs. In Rails projects you can also use gems and plugins to get a flying start. To avoid risks, try the gems/plugins before the project.

Hope you enjoyed this post. Next week I’ll be posting about the lessons we’ve learned in the development phase.