all bits considered data to information to knowledge

28Jul/140

Agile Methods for Disposable Software

I had a conversation the other day about agile software development with a friend of mine who is, by his own admission, a “real hardware engineer”. The focus was the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

According to my friend, these statements are “either trivial, or naive, or plain wrong, or all of the above”.

NB: He also coined a hilarious ADHDDD term - Attention Deficit Hyperactivity Disorder (ADHD) Driven Development – and wrote a manifesto worth reading if only for its literary merits  🙂

Of course, as a certified Scrum Master, I beg to differ - but his attitude illustrates the point when a method (or its perception) can be taken ad absurdum. One of the common themes is that in the past the software was “designed to last” and Agile tell the developers “don’t think – code” … As any agile practitioner knows - nothing could be further from truth. Most of the COBOL written in 1960 is still running – but is it a good thing?  Borrowing from my friend's area of expertise, electronic tubes can work in stead of ASIC  - and ,arguably, with greater transparency (pun intended 🙂 ) – but would you really want to? Agile development does not preclude solid software architecture – quite opposite, it demands it! The fundamental quality attributes of the system are defined (and designed!) before a single line of code is written, and then – in close collaboration with the stakeholders - the rest of the requirements are being fleshed out.

We are living in the age of disposable software. This is a trade-off we've made to get the “latest and greatest” now - and cheap (preferably, free!).  Just take a look how things have progressed since 1980s - CPU, storage, RAM - all plummeted in price, and packaged software prices went through the roof...  (the Open Source movement only changes costs model – instead of “paying for software” one begins “paying for support and additional features”).

It might appear that we are rushing the development a la Netscape experiment of the 90s where a barely compiled program was foisted upon unsuspecting customers to debug…but it is a superficial analogy. We came a long way since those heady days.  We have a number of tools and frameworks at our disposal to shorten the development cycles – requirements gathering, build, testing, release – until we are getting to a nirvana of “continuous build” (and when we think that things cannot get any better we are ushered in a wondrous world of “continuous deployment”).

Is it better – or worse -  than a top-heavy process that takes time to spell out every requirement in a minute detail? The answer is, of course, it depends. A working software just-in-time for the market – albeit a buggy one – trumps comprehensive but obsolete one every time!

“For to him that is joined to all the living there is hope: for a living dog is better than a dead lion.”   Ecclesiastes 9:4

12Jul/110

A SCRUM lesson from my horse

Couple weeks ago I went horseback-riding in Black Butte Ranch, Oregon. This was the second time I found myself trying to control a beast with a will of its own, and a physical strength vastly exceeding my own. Only “control” would be a poor choice of words - I learned quickly that I can’t control my horse (Big Jake was the name)… After initial disagreement on several points, I found that I was able to influence it, and in the end we both finished the trail in one piece.

Then it occurred to me that this might be a good metaphor for Agile Software Development (SCRUM and such). You can’t control your team without killing off all that makes it agile; you have to work with it, finding just the right balance that will get you to the destination, alive.

Tagged as: , No Comments