Wednesday, November 14, 2007

The Birth of Agile Development

Up until around 1980 or so, many software projects were carried out by what is called the "waterfall" approach: painstaking effort spent eliciting user requirements, publishing design documents, and coding to the specification -- often using COBOL.

The problem was that it was a rather slow process: no one can ever rattle off all of their requirements, accurately, and by the time the code was written the requirements may have genuinely changed. Using a language such as COBOL tends to make team write many lines of code.

In the late 1970's and into the 1980's, there was a movement of "fourth generation languages". The most notable of course was NOMAD2, and to a lesser degree FOCUS. NOMAD2 had a highly sophisticated DBMS, high level programming language, extremely rich set of functions, and the best report writing language ever seen. Corporations such as Bank of America and Chevron were early adopters of NOMAD2 and each had millions of lines of code in it.

This enabled developers to take the specifications and build a working prototype rather quickly, which in turn presented something visible and tangible to the user as opposed to having to rely on written documents and sketches of screen layouts. This process in turn fed back into a refinement of the specifications, and a better deliverable done more quickly than if previous methods had been used.

Perhaps without knowing it, the "agile" methodology had been born (this will, I know, contradict the belief that it was born at a ski lodge in Utah). 4GLs, as they were known, were used extensively in the '80s, but their use waned with the explosion of client/server technology (thus moving away from mainframes), Windows, event driven programming, and the rise of SQL as the de facto query language (which has yet to equal 25% of the abilities found in NOMAD2).

Like many worthy software products, most 4GLs did not make the transition to the Windows platform and we ended up with lots of C, C++, and VB, along with new DBMSs, most notably SQL Server and Oracle. In some ways we went back to 3GL coding, but with much more complexity, and so we rewound and the search for a "better way" got fresh legs.

Too often one can become part of a religious war of waterfall vs. agile, rather than focus on what practices will work best for the project and the team available. These thoughts will be explored more in future articles.


Project Management Software said...

Make the best use of consultants' knowledge
This is the fourth and final part of article on Success factors of an ERP implementation. We are sure this series of articles will guide our readers make their ERP system work effectively and successfully.

It Solutions LA said...

These people must have dedicated time to the project and they must be willing to be accountable for dealing with issues and making timely decisions. Many ERP implementations become paralyzed when issues are put on hold and are not dealt with quickly.