Software development has come a full circle states Alex Iskold in a scathing, pull-no-punches broadside upon the Waterfall model.

Read it here: the future of software development

Alex states that arrogance was the main problem with the waterfall model. The arrogance he argues came from the fact that we believed that we could always engineer the perfect system on the first try.

37 years ago, W. W. Royce published a sequential development model, coining what is now known as the waterfall model. This approach applied the insights from mature engineering disciplines (mechanical, civil, etc.) to software. The idea was to construct systems by

  1. first gathering requirements,
  2. then doing the design,
  3. then implementing it,
  4. then testing,
  5. and finally getting it out the door in one linear sequence.

Ironically, Royce actually argued in this presentation that this was a flawed and actually proposed what is known as iterative design.

37 years – a lot has happened, and we have come a long way and (hopefully) have learned a lot about making software.

However, in the real world, (and in other unreal places that I happen to work in) software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. This effect is compounded by the accelerating pace of business.

Older development methods completely fail to address business needs. The Waterfall Model is rigid and unrealistic and incapable of rapidly adapting to and keeping pace with the changes to the business.

Using the Waterfall Model, these

  1. changes were impossible,
  2. the development cycle was too long,
  3. systems were over engineered and
  4. ended up costing a fortune,
  5. and often did not work right. ;-)

In nature, dynamic systems are not engineered, they evolve.

  • Build small and then add on.
  • Model the Happy day scenario. Leave the esoteric corner cases for another day, another release.
  • You cannot and must not code for *all* the weird and *potential* use case scenarios
  • Build pluggable frameworks
  • Design to integrate
  • Leave the system open, and flexible

The solution to achieve these niceties, it appears is an age old one. In 1975 – (a few years after the Waterfall term was coined), Fred Brooks famously propounded that “Adding manpower to a late software project makes it later” in his book titled The Mythical Man-Month: Essays on Software Engineering. However we see this mistake repeated everywhere; and in every project that is going sour. “Throw-more-resources-at-it”, will probably get you a few more months out of your aging PC – but hardly ever speed up the project.

Alex evangelizes the adoption of agile methodology as proposes that in the future, software will be developed by “Just a Few Good Men” and provides a simple overview of Agile Software Development Principles:

  • Have Fun
  • Focus on Simplicity
  • Adapt the code
  • Embrace Change
  • Get feedback
  • Refactor
  • Communicate
  • Release Often
  • Test

.. and concludes with his forecasts for the future:

  • High-quality, passionate software engineers will be in very high demand and will make substantially more money. – Good!!!
  • The developers who do not have great programming skills are going to have to look for jobs elsewhere. – hmmm… why are they in this industry in the first place?
  • The changes that we are witnessing today in the social software market are going to reach the enterprise level. – SAS? the Web is the computer?
  • Software off shoring will make less and less economical sense. – why so? does agile software development going to make the world less flat?
  • Computer science is going to remain a highly competitive and prestigious field. – sure hope so.

While I agree with Alex’s theme in general, with respect the Agile methodology adoption, I fail to see why off-shoring would get affected by this; Unless this this is was just a general comment.

On this topic, I had a brief chat with a colleague of mine, another proponent of the Agile methodology himself, and he argued

  1. it would not be possible to have synergistic agile teams across the seas and across timezones.
  2. Agility would be impeded due the overhead of heavy documentation; people would not understand the business properly otherwise.
  3. it is not cost effective to have several delivery dates from offshore

I smiled in reply – it will evolve.