The Advent of Agile Software Engineering Methodologies

written by Cyx on December 5th, 2005 @ 07:15 PM

Slow and painful software development process

In the olden days of software engineering, there were several proccesses used to make software. The Waterfall Model for example, facilitated most of the design processes which teams followed religiously. This consisted of a very, very long requirements analysis phase, followed by top level design. Only then will coding begin, and then testing. Successive iterations repeating previous steps are done until a final product has been engineered. This used to work, and yes, a lot of companies employed this approach for years. But why does it appear to be a lost path?

In my opinion, enterprise software design back in the days involved a semi static design flow, much of which were reconstructions of manually devised and well documented business processes that needed automation. Systems such as ERPs, Patient Registry Systems and Banks involved a roughly steady domain model, where much of the requirements analysis have been done through time.

But in this age, where being different and staying on the bleeding edge of entrepreneurship decides which company gets more customers and therefore more money, businesses are trying to make systems from thin air. They have an idea, obviously not possessing comprehensive business process documentation, since they themselves are figuring out what the rules of the system will be. Software development companies who try to apply the processes designed by our predecessors most likely are doomed to fail, since the static techniques employed by those approaches demise change.

XP to the rescuse
eXtreme Programming is a software engineering process which aims to lower the cost of change. As mentioned above, the dynamic and changing nature of businesses demand instant changes, with fast feedback. That’s what XP is all about.

The core design principles of XP are as follows :

1) Fine scale feedback – using Test driven development, pair programming, an “onsite customer” and the planning game.

2) Continuous process rather than batch – instead of long ang cryptic batch processes, XP favors short and fast iterative cycles with the help of refactoring and continuous integration.

3) Shared understanding – in any system, a simple design, defined set of conventions and coding standards, and agreed upon system metaphors help the team to understand the problem better as a whole, rather than disjoin parts.

4) Programmer welfare – unlike the old processes where a project manager decides the pace, XP favors little overtime, leaning towards a sustainable pace.

XP has proven itself time and again. Thoughtworks, for example, has evangelized their software development processes and have proven time and again, that it delivers faster, with better / more reliable code, and most importantly happier customers.

sources :

Post a comment