Click here to Skip to main content
12,821,084 members (38,187 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


Posted 25 Oct 2010

One Hour Iteration, or How Much Agile is Too Much

, 25 Oct 2010 Apache
Rate this:
Please Sign up or sign in to vote.
One Hour Iteration, or How Much Agile is Too Much

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. :)


This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0


About the Author

Ivan Krivyakov
Technical Lead Thomson Reuters
United States United States
Ivan is a hands-on software architect/technical lead working for Thomson Reuters in the New York City area. At present I am mostly building complex multi-threaded WPF application for the financial sector, but I am also interested in cloud computing, web development, mobile development, etc.

Please visit my web site:

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170308.1 | Last Updated 25 Oct 2010
Article Copyright 2010 by Ivan Krivyakov
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid