>Yes, but one point about redoing the application is that we have to go back to square one when comes time to start the testing phase.

In some cases maybe - but not always.

Most projects are over "teamed" - A 12 team shop once took 5 years on a project. There were replaced by a one guy team that delivered a (better by orders) solution in less than a year.

As much as we wish it were't so, the problem is that a large team, as comforting as it is to project managers, is no substitute for skill.

What to know?
Deliveries should be phased. A good craftsman will look at the problem and define every aspect of the project before one line of code is written.

How can you get there if you don't know where you're going?

A project is like an onion (:-). A "can do" craftsman will design the "onion" from the center most "layer" out.

Each layer is a phase.

Each layer can be designed, coded, alpha tested and delivered as a standalone (including the modules reports, etc) to the user for a "modular" beta and review. This means change requests and beta debugs can be in process - and the revisions can be implemented in subsequent layers as they are completed and delivered.

Each layer,delivered this way, from the outside in until the center most layer, the "nut", where the transaction service reads and writes the previously delivered "outer layers".

An onion.

Why teams? Really, why? A team only needs the users, a real developer (with a real - and bright apprentice to train as his replacement, a DBA web guy (and his protoege) and 2 techs.

And salesman.

There are only two advantages that to big teams (weren't the new tools and paradigms supposed to eliminate that "requirement"?)
1 - it keeps team leaders employeed:-).
2 - When problems and the help desk's phone rings off the hook, and this, coincidentally, coincides with MS's next DOT NEW launch - the team, who couldn't deliver with yesterdays tool, can now tell the boss the problem will be solved by MS's DOT NEW! (In a few years they will be the team who "couldn't do" in the DOT NEW either!:-)

And desperately seeking DOT NEW II!

Good story for the boss - good story for the customer - great story for team leaders and MS!

And you know what - everybody always falls for it.

Don't resuse legacy code - use the interface and get the users to tell you the story. But don't reuse it.

Sure, look at code in case of exotic algorythms. Everyone, at least once in their career, need a DOS C trace running in one window and the VFP debugger in another - running down that sweet spot.

If the new project has to "literally" reuse all the legacy source, don't by the project. At least [not] from that developer.

Just copy the old one from the floppy disks to a CD and call it "new". Same diff!

People should know how to flesh this out.

The skill level of so called developer "pool" atrophies (books and DOT NEW cults scream at us).

Development tools get all mushy and fat to accomodate the [ever lowering] attention span of the nations programmer pool. As we attempt to sell our customers "lowered" expectations at a higher cost, they begin to out source off shore. Foreign developers then politly kick our "recompile in DOT NEW" pansy butisimos into a cashiers job at Wal Mart.. They're hungry, well educated and cheap!

Politics and the "big guy's naivity (AWA job security for middle of the road middle manger IT types!) allows MS to turn software developers into lacklustered MS repair guys! It's the "crappy guy" syndrome all over again!

RANT OFF