|
|
Plan B - DevGuide revisited for 2012 |
2012/04/02 |
From the last exciting episode: You've got an existing application that needs to be upgraded/replaced. In essence, the problem posed is now "We have no specification, but we still need to know how much it will cost." The answer is still "it depends."
Management and Accounting won't be thrilled with that answer, because their ledgers don't have a space for that choice.
Plan B is to build a small but completely operational application that performs the most important function in system, and then quickly add more modules, one after another, Instead of writing specifications for weeks or months, and then laboriously constructing a behemoth of an application that doesn't get delivered for even longer, the idea is to deliver early - and deliver often - until you don't want to spend any more money.
Put a nicer way, the idea is to continue working until you're no longer getting value for the money you're spending.
The homeowner equivalent would be to create a simple house, with a kitchen, bedrooms, bathroom, and a roof, and then add more rooms - living room, den, screen porch, garage, as desired. If the original design is done with the intent to add on, the house will look like it was built in one pass.
With software, of course, this is easier to do, as there are no walls to punch out, windows to move, or roofs to expand.
A common request is whether we can use the current system as the 'specification' for the new one. Typically, the answer is no. Here's why.
- Part of the current system isn't being used anymore due to changing business needs.
- Part of the current system needs to be changed due to new business logic.
- New functionality has to be added due to new or changed requirements.
- The technology available when the old system was built had limitations that do not exist with current technology. Thus, functionality that was implemented a certain way due to those limitations can now be implemented a better way.
While this Plan B may not appear to be ideal, it actually is perfect. As I've told my authors, when they asked how long their book should be, "Write until you're done saying what you have to say. Then stop." Here, continue spending money on the conversion as long as it's a good investment. Once the development is no longer valuable, stop.
|
|
|
|
Download Updates
8/30: FoxRockX Issue July/August 2012
has been posted.
|
4/26: FoxRockX Issue May/June 2012
has been posted.
|
3/9: FoxRockX Issue March/April 2012
has been posted.
|
2/1: FoxRockX Issue January/February 2012
has been posted.
More)
-->
|
1/25: Software Developer's Guide wiki has been updated. Email for details. |
1/1: FoxRockX Issue November/December 2011
has been posted.
More)
-->
|
1/25: Updated source (Ch 7) for What's New in Nine: Visual FoxPro's Latest Hits
has been posted.
More)
-->
|
1/21: Updated source (Ch 6) for MySQL Client-Server Applications with VFP
has been posted.
More)
-->
|
|
|