Software development’s history is littered with high profile project failures. AIL’s starting point when defining the way it approaches development was to ask why this should be the case.

History

Before the development of structured methodologies software development was a chaotic activity without much of an underlying plan; based on short-term decisions. This approach can actually work, but only for small short-term developments. As projects grow in complexity, working this way rapidly becomes a recipe for disaster.

Early methodologies tried to address this by drawing on older engineering principals, putting a heavy emphasis on planning before building. Typically the construction industry is cited, where experience shows that the design stage is highly unpredictable, absorbs 10% of the cost, and relies on skilled creative professionals. This compares with the build phase, which is predictable, but absorbs the other 90% of cost. Requirements are gathered during the design stage, and once this stage is complete the cost of requirement change can be enormous.

The early methodologies consider requirement gathering, and system modeling to be the equivalent of the construction industry’s design stage, whilst coding is equivalent to the build stage. However, as Steve C. McConnell observes in his book “Taming Wild Software Schedules”: coding can be expected to absorb only 15% of a software project’s costs, while the highly unpredictable design stage takes the other 85%.

This mismatch is the major reason why these methodologies fail, and why AIL doesn’t use them.

AIL’s approach

So, is software development simply an unpredictable process? The answer is no; but the parts that are completely predictable, like compilation and linking, have been reduced to automated processes which are so cheap as to be considered free. What’s left is entirely design.

As in the construction industry, design in software development is unpredictable. This demands an adaptable approach; one that accepts, even encourages, change at any point. AIL uses just such an approach.

Our approach is evolutionary, based on small phases each delivering a working – and increasingly feature rich – system which clients can use and test to their satisfaction. This means that clients start to use the system very early on, making it much simpler for them to spot problems or issues with the requirements.

In an adaptive process, like AIL’s, the customer has very fine-grained control over the software development process. At each phase they can both check progress and, where required, alter the direction of the project.

This leads to much closer relationship between AIL and its clients, a true business partnership.