Freigeben über

When "Quick Win" is an oxymoron

  • Artikel

I know of an excellent project that was spun up in a hurry to write a small amount of really tough code and roll it out.  It was a "quick win" project, so named because you can get value out the door quickly. 

I say "was" for two reasons. 

One: the quick part is over.  It is going into production.  Now comes the really slow part: owning it.

Two: the Win part is over too.  It's value has been demonstrated. It reduced cost or increased capability as expected.

The problem with a "'quick win" project is that code, quickly written, requires quick replacement. 

Now that this code is in production, it is time to purchase a commercial package, for less money, and greater capability, to augment it.  The alternative is to slowly, expensively, add one feature after another until the IT group has written so much code that they will hold on out of pride, even though a commercial package is (a) available, (b) less expensive, and (c) more fully featured. 

You see, if you invest in a quick win, you have to settle for the quick replacement that follows.  Otherwise, you are taking a success and letting it sink into failure.

Comments

  • Anonymous
    April 13, 2007
    PingBack from http://www.rss.architectfad.com/when-quick-win-is-an-oxymoron.html

  • Anonymous
    April 13, 2007
    Quick Wins are rewarded by the management-by-quarter method of doing business. The value of the win only exists during the quarter and therefore, another quick win must be created in the following quarter. The pattern has a positive feedback loop.

  • Anonymous
    April 13, 2007
    I disagree.  You cannot solve a problem with the same thinking that created it. Each "quick win" project builds up developer debt.  (For people outside the agile development circle, developer debt is the notion that developers, making short-sighted decisions, are leaving code for someone else to refactor, and that it is nearly always more expensive to fix the problem later.) Quick win projects build up "architecture debt".  You can do one.  You might be able to do two.  But you are going to hit a 95% likelihood of failure at the third.   So, the only time this creates a positive feedback loop is when the business leader gets to claim victory and then change jobs before the bill comes due.  (It's a little too common, even then).