When Green Fields Become Killing Fields

If you ever consider taking on a greenfield project to replace a working production system that, though it is a big ball of mud, continues to improve and runs on a reasonably modern OS such as Linux or Windows, weigh the risks carefully.  The legacy system has hundreds of useful features that will have to be recreated in the new software.  Think about how much effort has gone into the development of the legacy system.  Even if you believe the greenfield will do it faster, be realistic about how much faster.  For example, if the legacy system was developed over ten years, can you really deliver a better replacement in under two years or more than three times faster?   Consider also that your shiny new system will not be proven in production until it can get to production, which may add months to the end of the schedule or cost your business in lost productivity when the new system proves initially more unstable than the legacy system.  It is often better to take the resources you planned to dedicate to the re-write and use them to gradually carve off and replace pieces of the legacy system instead so that you end up with what you wanted in the first place: something just like the existing system but more reliable and easier to maintain.  It may take a little longer and cost a bit more, but it is actually far more likely to succeed because it delivers incremental business value along the way.

If you do decide to march across the greenfield anyway, please consider Pickett’s charge for an example of how deadly the combination of a beautiful greenfield and the illusion of quick victory can be.

On a sunny summer’s day on July 3, 1863, General George Pickett lead his men on an ill-fated march into history:

After the great guns fell silent, three divisions of resolute Confederate infantry, around 12,500 men, stepped out from the trees and formed battle ranks. Stretched out in a battle line over a mile long, with fixed bayonets and flags flying, the Southerners began their slow, determined march up towards Cemetery Ridge, three-quarters of a mile away. Waiting on top, the Union troops crouched behind stone walls, watching and holding their fire. When the Confederates were halfway across the intervening field, the Northern artillery opened up and began tearing great holes in the approaching lines. As the Southerners drew nearer, the Union infantry unleashed volley after volley of musket fire, mowing down the advancing enemy. Somehow the ragged lines kept reforming and on they came, despite the devastating carnage, quickening the pace and howling their “Rebel yell.”

— An account in the Philadelphia Enquirer

General Lee ordered the attack despite the reservations of his second in command, General Longstreet, because he felt the Union army would break under the assault, his army would march on to Washington and the war would be won.  Longstreet, on the other hand, had long ago come to the conclusion that new technology made assaults against entrenched defenders on better ground sheer folly.  He had watched as the Union had assaulted General Jackson’s strong defensive position at First Manassas back in 1861 only to be slaughtered by the thousands.  He did not want to see the Army of Virgina suffer a similar fate assaulting the hills of Gettysburg.  Instead, he suggested a flanking maneuver around the immobile Union defense so that the Confederates could take up a strong defensive position between the Union army and Washington thereby forcing what he believed would be a costly Union attack.  Lee, likely tired and sick, would have none of it.  He wanted to bring the war to an end and he thought his men would once again do the impossible.

History, in the form of the cannons of the Union army, ultimately proved Lee wrong.  Thousands were slaughtered as they marched bravely onward.  A contemporary Union newspaper account tells of the gruesome climax:

A few hundred Southerners, bravely led by General Lewis A. Armistead, breached the Union lines and briefly hoisted the Confederate flag on top of Cemetery Ridge before being overcome. The rest of the Southern troops could not even reach that point, and were forced to turn back.

Their battle-flag was planted boldly upon the crest and a shout went up from the demons who seemed to court death and destruction, but our lines swayed but for a moment; back they went, the ground was regained, and our lines again intact. At other points they succeeded in gaining temporary advantages, but ere they could realize their importance they were torn to pieces and hurled back upon their column, and so the column swayed until they could no longer get the troops to make a charge.

— An account in the Philadelphia Enquirer

Nobody knows what would have happened if Lee had listened to Longstreet that fateful day.  Perhaps the war would have dragged on even longer before the Union’s economic and population advantages ended up carrying the day.  Perhaps some European power would have stepped in to negotiate a peace with the Confederate states remaining independent.  The only certain thing is that the Confederates never again threatened ultimate victory despite fighting on for nearly another two years.

 

Estimating with Fogbugz

I spent the weekend putting together a task list and estimates for Onpoint Connect. We use Fogbugz for issue tracking but I always found it a little underpowered for estimating; Even though they added Evidence-Based Scheduling (EBS), there were a number of things missing that made it difficult to build a good estimate that could actually be discussed with other managers. Most notably, it was not possible to setup high-level tasks that contained a number of detailed sub-tasks. I am pleased to say that this has changed in Fogbugz version 7. The subscase feature allows you to create more detailed (estimatable) cases that roll-up into their parent cases. I used this feature extensively to end up with a list of about 10 major cases to discuss with management that contained the much more detailed and numerous cases for the developers to estimate. The EBS algorithm combines the estimate data with historical data on the developer’s estimate accuracy to figure out the probability of completion by certain dates. Fogbugz will even track the estimated work remaining and probable completion dates as they change and show me the trends. Version 7 of Fogbugz has a number of other improvements that impact scheduling including dependencies between milestones and the ability to distribute staff resources across multiple projects.

Fogugz continues to include well-designed features for handling support cases, support email and documentation. The new version has a plug-in architecture and available plug-ins to add features that help with agile development, time reporting, documentation and user stories. The bottom line is I can now recommend version 7 of Fogbugz as the ideal tool for issue tracking, scheduling and documentation for development teams using almost any methodology. It is available as a hosted solution ($25/user per month) or for installation ($199/user). Make sure to check it out.

I spent the weekend putting together a task list and estimates for Onpoint Connect.  We use Fogbugz for issue tracking but I always found it a little underpowered for estimating; Even though they added Evidence-Based Scheduling (EBS), there were a number of things missing that made it difficult to build a good estimate that could actually be discussed with other managers.  Most notably, it was not possible to setup high-level tasks that contained a number of detailed sub-tasks.  I am pleased to say that this has changed in Fogbugz version 7.  The subscase feature allows you to create more detailed (estimatable) cases that roll-up into their parent cases.  I used this feature extensively to end up with a list of about 10 major cases to discuss with management that contained the much more detailed and numerous cases for the developers to estimate.  The EBS algorithm combines the estimate data with historical data on the developer’s estimate accuracy to figure out the probability of completion by certain dates.  Fogbugz will even track the estimated work remaining and probable completion dates as they change and show me the trends.  Version 7 of Fogbugz has a number of other improvements that impact scheduling including dependencies between milestones and the ability to distribute staff resources across multiple projects.
Fogugz continues to include well-designed features for handling support cases, support email and documentation.  The new version has a plug-in architecture and available plug-ins to add features that help with agile development, time reporting, documentation and user stories.  The bottom line is I can now recommend version 7 of Fogbugz as the ideal tool for issue tracking, scheduling and documentation for development teams using almost any methodology.  It is available as a hosted solution ($25/user per month) or for installation ($199/user).  Make sure to check it out.