Agile programming is called “agile” because it provides faster feedback cycle than traditional methods.
In the traditional world, first you write a functional specification document. Then you have the users “sign off” on it, which takes weeks or even months. Then go away into your coding cave, and within a couple of months (or years) produce a shiny product only to discover that anything that can be misunderstood was misunderstood. And the users go “yes, we may have said we need it half a year ago, but this is not what we want”.
There is, however, an opposite side of the spectrum: instant gratification development. This kind of development breeds in highly dynamic business environments such as hedge funds, where Excel Macro is king, and yesterday’s data is well forgotten past.
This development “process” has only two basic rules:
1. Any task must be completed and demoed within several hours (ideally), or 1-2 days. If it takes longer than 2 days, it is too long.
2. There can be only one pending goal at any particular time, and it must be achieved as quickly as possible (see #1). Anything that does not directly serve the current goal is a waste of time.
These rules produce a number of corollaries:
C1. Test plans are a waste of time. They would use old data that by definition is a pile of garbage. We can’t afford to spend our time testing useless things. We must do business.
C2. Putting requirements in writing is a waste of time. Anyone with a half brain can remember the single outstanding requirement. Other requirements are either already implemented, or don’t matter.
C3. Bug tracking is a waste of time. Anyone with a half brain can remember the single outstanding bug. Other bugs are either already fixed, or don’t matter.
C4. Refactoring is a major waste of time. It is dangerous and delays accomplishment of the current goal.
C5. Any programming construct fancier than a “for” loop is scary and it is probably a waste of time.
C6. Anyone who says that hacking the software till 11PM on Friday night is unnecessary and dangerous, is a lazy renegade, and must be dealt with accordingly.
This is as “agile” as it gets. This kind of environment is ideal for doing trades or producing prototypes, but it is not suitable for producing working production software. The tragedy is that the business owners are sometimes so entrenched in this mentality, that they resist any attempts to change it. Under these circumstances, developers have three choices, each worse than the other:
– shut up, submit to the process and be blamed for all failures
– speak up, be blamed for low morale and ultimately get fired
– walk away
But whatever the choice, please don’t call it agile 🙂