At any given time, a big software shop like Microsoft will have several versions of the same product in process. For instance, the next release of Windows is being created right now, but the release beyond that and the one beyond that are too. Microsoft clearly decides how much they can put into the system to get it "on the shelves" in a reasonable time and how much they're going to have to put off until the next one comes out. Another benefit of this is that you can make sure that everything in the next release will be compatible with what you're planning for future versions. You don't shock the customers with too much change all at once (They missed this goal with .NET ... it's a shocking change!) and you can pace software demands with hardware availabilty.

Even our little system can benefit from some of that thinking.

In this version, we will add a TextBox control so that people using the program will be able to change phrases to be added into the document without changing the source code of the program. But adding a TextBox isn't not the only way to do it. MailMerge, for example, requires that you build a file of the text that you want to merge into a document. That's not a bad idea and it's an obvious upgrade for this program ... but we'll put it off until the next release. Another change that would do the system a lot of good would be the ability to specify a file location for the template file. We'll do that one 'next time' too. But these are great examples of what you should be thinking about before sitting down to code.

Before we leave this topic, you might run into some TLA's (Three Letter Acronyms) that are a slightly different point of view. RAD and JAD. RAD stands for Rapid Application Development and JAD is Joint Application Development. First, these things mainly concern professional programmers in big development organizations. As a beginning programmer, you don't have to concern yourself with trying to learn them. But second, a lot of people take introductory courses like this so they can understand more of what the professional programmers are saying ... so I thought this might help that segment of the audience.

In really big projects, the analysis can go on for literally years before much of any code at all is produced. And it can cost millions before any code is produced. Sometimes, quite a few millions. Finally, many companies have spent those millions only to discover at the end that there wasn't going to be any code produced! In other words, the project failed because it fell into an 'analysis paralysis' pit for too long!

Partly as a reaction to this sort of thing and partly because many people think it's a genuinely better way to go, some projects adopt a philosophy of creating actual code as part of the analysis process and involve users in running incomplete programs well before the whole system is finished. In fact, Visual Basic is used a great deal as part of these RAD and JAD projects because it's possible to create Visual Basic systems very quickly ... or at least systems that look really good if you don't try to stress them too much.

In my opinion, this is a false hope. From personal experience as a project manager of large scale development, I believe that projects don't fail because the analysis goes on too long and becomes too complex. I think they are usually 'management failures' because they were started with incomplete or unrealistic goals; management changes their mind part of the way through the project; or (face it) they're just poorly managed while they're in process. Excessive analysis is a convenient scapegoat for the failures, however.

Anyway ... enough of this 'analysis paralysis' in this segment! Let's get to some actual coding of our own in: