Reduce development time by optimally sequencing your tasks

Introduction

This article points to the impact of development sequence on the delivery date; particularly for Agile projects.

Making the choice

Every day, software developers face many features to be coded or bugs to be resolved. The choice made helps determine if the product or iteration meets the due date. This choice is more important for the Agile developer than the Waterfall developer. By definition, an Agile developer spends less analysis time up front on requirements, architecture, and design. The risk incurred by doing less analysis is that there is a greater chance that there is a flaw in the architecture and design. Therefore, Agile developers need to take steps to expose the flaws in their design and architecture as soon as possible.

One technique for uncovering design flaws is to implement the code based on the design. The sooner you write the code based on the design, the sooner you will discover the flaws in the design. You should write at least enough code to prove the concept of your design in as many areas as possible. For example, we developed an application with many business classes using nHibernate to work on both SQL Server and Oracle. We wanted to use transactions to update multiple tables at a time, and we wanted to lock records pessimistically. We developed a customer class that could select, insert, update, and delete. The class did not implement all the properties we wanted yet, so we had a choice of development paths, and we could:

• Spend time to add more properties to the customer class
• Spend time writing the select, insert, updates, and deletes for other classes
• Spend time implementing locking
• Or spend time implementing transactions.

On the surface, all of the work had to be completed at the same time, so it may appear that the order is irrelevant. But this was not the case for us. We chose to implement the locking code in our customer class next, and discovered that we had to change the existing code and database structure of our customer class. If we had waited until the end to write the locking code, we would have had a lot of classes and tables to refactor and re-test.

In waterfall, you often spend a lot more time on design to prevent such problems because reworking a lot of existing code takes too much time. In Agile development, you can also reduce the impact of design changes by testing the design early in the process.

When choosing which task to do next, choose a task that will test a new aspect of your design.