Keep it coming

The world has ended up where software implementers hope the customer will have a problem that fits in with generic software systems that have already been written. Most of the software currently installed is underutilised, because the customer had to buy a larger system in order to get the specific functionality he really wanted. Competitive advantage is becoming progressively hard to come by - because every company's software comes out of similar boxes and addresses generic business issues only.

How the industry lost its way:

In a way, the industry is coming full circle, back to custom software.

The generic systems of today replaced, at considerable cost, earlier systems that started out as custom software. Custom software had proved to be costly and risky, because development models were usually haphazard.

By contrast, generic systems imposed standards, and eventually, best practice, reducing cost and risk and making all implementations look the same from all angles. They assured companies that they weren't pioneering and that they were on the same playing field as their competitors.

But, standards have a way of being intractable. The rate of proliferation of new technologies and changes in customer expectations of technology are outstripping the rate at which generic software can be renewed - or written from scratch.

So, the pressure is on to shorten software development cycles to enable companies not just to keep pace with market shifts, but actually get ahead of or lead them.

The only realistic way to do this is through agile software development, and its child, continuous development. Continuous development is a practice where members of a team integrate their work frequently, usually at least once per day.

The IT industry chose to go a more nervous route dictated to by sceptical clients who didn't want to be guinea pigs again.

These integrations are verified by an automated build (including test) to detect integration errors as quickly as possible.

However, although agile development was conceived 20 years ago, and continuous development has been practised for several years, the IT industry chose to go a more nervous route dictated to by sceptical clients who didn't want to be guinea pigs again.

The principles expressed by the Agile Manifesto are remarkable, not least because they emphasise value for the customer, maturity of behaviour, and trust in developers rather than procedure, rules, and documentation.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity - the art of maximising the amount of work not done - is essential.

11. The best architectures, requirements, and designs emerge from self-organising teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Based on confidence rather than fear, the manifesto was ahead of its time. Trying to reduce the early individualistic element of software creation, developers borrowed the 'waterfall model' from the manufacturing and construction industries. A sequential design process, it moves through the phases of conception, initiation, analysis, design, construction, testing, production or implementation, and maintenance. Its rigidity all but eliminates after-the-fact changes.

The flaw in this thinking is that organisations change constantly. So does technology.

The industry moved to the more flexible 'spiral model', which focuses on producing staged prototypes. The trouble is, prototypes are usually thrown away. Wastage and user confusion was inherent in the model.

Agile and continuous development, however, are based very simply on user feedback about small chunks of software. Rather than build an entire Web site, the 'log-in' page is built first, for example. When that's working the way the company needs it to, then the 'about us' page is built. Because the team is getting user feedback early - and it's writing tests before it writes code - it is catching bugs early, and perfectly naturally, constantly improving the product.

The customer has something to go to market with from the get go. His return on investment is immediate and substantial - and keeps improving with each iteration of software. That is, it keeps improving every few days!

That's about as short and effective a development cycle as the customer can hope to get. And that's custom software as it should be. Square one never looked this good.