When I used Procomm to develop (!) my first software in 1989 for Deccan Herald, a newspaper company based in Bangalore, it didn't seem to be a great activity. Of course, family members went ga-ga over my newly acquired skills and the amount of money that the effort brought in! In fact, I remember my father was almost glad that he had got back more than half the money he had spent in educating me and lavishly gifted me a good percentage of it!!
The approach was simple and I remember using a character from the character set to create a splash screen that evoked an envious "Hey, is this a Unix program?". In those days, anybody who programmed for Unix was considered to be a great techie!! The only time that I had a tryst with Unix was to use a dumb terminal to play PacMan!
I went into a non-IT profession, part-time, for about 3 years and returned to the IT industry in 1992 or thereabouts with my own company called "Semantix Computers". Looking back, even starting my own company did not mean a lot, as very few Airline companies, big institutions and travel agencies ( to impress their Airline friends) actually went for customized software development!
The first thing that comes to my mind when I cast my mind back to those days is the simplicity with which I used to work with the customers. The requirements were clear because the customer did not know what she wanted !! So, I had to patiently and correctly understand the requirements to the extent whether the customer wanted the print to be on a dot matrix printer or on a Laser Jet (the new swanky toy then!) printer!
If the software crashed, no worries! The customer could be told, "Please restart your machine!" and if the customer said, "I had forgotten to save my data. Does this mean that I cannot recover them now?" Not irate, not cursing! Just a simple query that would be met with, "Please remember to save frequently from now on" and you could actually chide the customer !!
Today, the same scenario possibly may exist in a rural village deep in Nagaland or in a pygmy country!
Requirements gathering, which has often been touted as possibly the most difficult of all phases of the SDLC, is missing just that one thing - the naive, trusting customer!! The customer, today, is far more educated than his predecessors as are the users and consequently, the definition of Quality, too, has changed. The growing competition in the market makes that revered Unix programmer almost a liability and a techie, who stresses on extensive documentation, a sure shot recipe for project failure. And, project failures across many studies have all identified, "Requirement changes" as the top reason for IT project failures with organizational and IT letdown as a close second.
This dread of requirements changing has possibly been the furore behind the Agile Development approach and the subsequent "dryndrome" that has emerged out of this race to become Agile!
A "dryndrome", it is, because of the dread that has driven its adoption.
Looking back to the early days of software development in India, I attribute the success of Agile methods to the increasing lack of clarity in the approach to software development. It is as simple as this; if you have not understood the requirements, it is natural to get this phase clear before going ahead with design or implementation!
There is no substitute for natural stupidity as there is no substitute for common sense. And since these are the essential elements in any sanity check list in a SDLC, that people are still failing despite have adopted Agile methods is a clear indicator that a method becomes madness if not understood correctly and not applied in the right context.
The number of interpretation that Agile methods have been subjected to is mind boggling! What has emerged for me to understand from my various interactions with the wannabe Agilistas or the wannabe Agile organizations is just this - if you do not have a first hand experience of the evolution of the IT industry in India then you will find it very difficult to truly understand what, why and how Agile is and, why it should be adopted and not implemented!!!
The "dryndrome" is likely to continue and the race for adopting Agile is likely to result in a few more newer Agile methods to satisfy the partially baked palates of the enthusiastic wannabes!
The approach was simple and I remember using a character from the character set to create a splash screen that evoked an envious "Hey, is this a Unix program?". In those days, anybody who programmed for Unix was considered to be a great techie!! The only time that I had a tryst with Unix was to use a dumb terminal to play PacMan!
I went into a non-IT profession, part-time, for about 3 years and returned to the IT industry in 1992 or thereabouts with my own company called "Semantix Computers". Looking back, even starting my own company did not mean a lot, as very few Airline companies, big institutions and travel agencies ( to impress their Airline friends) actually went for customized software development!
The first thing that comes to my mind when I cast my mind back to those days is the simplicity with which I used to work with the customers. The requirements were clear because the customer did not know what she wanted !! So, I had to patiently and correctly understand the requirements to the extent whether the customer wanted the print to be on a dot matrix printer or on a Laser Jet (the new swanky toy then!) printer!
If the software crashed, no worries! The customer could be told, "Please restart your machine!" and if the customer said, "I had forgotten to save my data. Does this mean that I cannot recover them now?" Not irate, not cursing! Just a simple query that would be met with, "Please remember to save frequently from now on" and you could actually chide the customer !!
Today, the same scenario possibly may exist in a rural village deep in Nagaland or in a pygmy country!
Requirements gathering, which has often been touted as possibly the most difficult of all phases of the SDLC, is missing just that one thing - the naive, trusting customer!! The customer, today, is far more educated than his predecessors as are the users and consequently, the definition of Quality, too, has changed. The growing competition in the market makes that revered Unix programmer almost a liability and a techie, who stresses on extensive documentation, a sure shot recipe for project failure. And, project failures across many studies have all identified, "Requirement changes" as the top reason for IT project failures with organizational and IT letdown as a close second.
This dread of requirements changing has possibly been the furore behind the Agile Development approach and the subsequent "dryndrome" that has emerged out of this race to become Agile!
A "dryndrome", it is, because of the dread that has driven its adoption.
Looking back to the early days of software development in India, I attribute the success of Agile methods to the increasing lack of clarity in the approach to software development. It is as simple as this; if you have not understood the requirements, it is natural to get this phase clear before going ahead with design or implementation!
There is no substitute for natural stupidity as there is no substitute for common sense. And since these are the essential elements in any sanity check list in a SDLC, that people are still failing despite have adopted Agile methods is a clear indicator that a method becomes madness if not understood correctly and not applied in the right context.
The number of interpretation that Agile methods have been subjected to is mind boggling! What has emerged for me to understand from my various interactions with the wannabe Agilistas or the wannabe Agile organizations is just this - if you do not have a first hand experience of the evolution of the IT industry in India then you will find it very difficult to truly understand what, why and how Agile is and, why it should be adopted and not implemented!!!
The "dryndrome" is likely to continue and the race for adopting Agile is likely to result in a few more newer Agile methods to satisfy the partially baked palates of the enthusiastic wannabes!
No comments:
Post a Comment