Qbasicnews.com

Normally, I sit at my desk in math and begin to draw in my sketch book. I then take those sketches home and work on them until they are done. normally i will find something in one of my sketches that inspires me to make a game or a program.

QB is for fun and I get fun coding. So I just code. Algorithms come on their own.

For bigger, more important projects I use UML.

I've found that when I want to start writing a game or some program in QB, what I'll do is think about it for a few weeks.... (not constantly of course). What I do is think of the program in my head until I get to a roadblock, where I can't get any further in the program because of this problem or that problem, etc. Sometimes I'll even go over code that I've concluded would work just fine, and accidentally find that there was a problem with it. Anyways, when I get to a dilemma or problem in my head, I usually take a break from thinking about it for a few days or maybe weeks. Then, one day, the answer will pop into my head! So I move on, and continue with this process.... when I've come to the decision that it's good enough in my head, I start to code it in QB. Often times, I'll find that I miscalculated a few times, and a whole SUB or sometimes even the whole program might need to be rewritten. Also, when I get pretty deep into writing the program, I usually realize that I hadn't thought far enough into the program before I started coding, and I'll be caught at a roadblock so big, it makes me give up coding the program (sometimes forever!). Yeah. That's it.

Good code is thougt through. Well documented. Worked on in small peices. And designed with expansion in mind.

Dave,
Here's some ideas about project/program development from a real pro, George Trimble Jr., a great guy that I had the good fortune to work with back at Computer Usage Co. New York in the 1960's. The full text of his memoirs is at
http://mywebpages.comcast.net/georgetrimble/A.html

Here's an excerpt applicable to your thinking. I suggest you read it all ---- you especially will appreciate it.

Development WorkBook (DWB)
Over the years I have developed a Management Control/Documentation technique that has proven to be very useful and effective. I call it the Development WorkBook. It started out as nothing but a sheet of paper with the project name, the date, the programmer's name, and a title. The pages were placed in a three ring binder and available to all of the people on the project. It has evolved into a highly structured organization of all of the information generated and required to manage a project.

With the advent of networks, the DWB can now reside on a server or other commonly available data file. The principle is that all information pertinent to a project is contained somewhere in the DWB. This includes not only requirements, design specifications, detailed program designs, test plans and procedures but also administrative material, such as schedules, hardware configurations, user manuals at various stages of development, and contractual or other reference documents, either directly or by reference, as well as notes and memos.

There is a spot for everything pertinent to the project, and everything pertinent should be somewhere in the workbook. The organization, once one becomes familiar with it, enables the user to locate material fairly quickly. The DWB enhances project management and control by increasing visibility. For example, if a program design specification is due on a certain date and the design specification is not in the DWB, you know that part of the project is late. If the specification is there on time, it can be determined if it is adequate or whether potential problems exist for that particular item. The DWB facilitates program reviews, program walk-throughs, and finding inconsistencies or holes in the system's design and implementation.

I strongly feel that one reason software development projects are late and overrun their budgets so often is a lack of control. Yet programmers vehemently resist the idea of documenting their programs, want to start writing code on day 2 of the project, and promise to document when they are done, but never do. Managers see this approach as non-productive (code is not being written), taking extra time, and costing more money. Someone once asked me, on a $300,000 project, what it would cost if we didn't do all of this "paper work." My answer was, "It will cost at least $600,000 and won't be done on time." If you don't do it right the first time, you will have to do it over or will spend lots of time and money on program maintenance.

It doesn't have to be done using the DWB. That is just one structured means of controlling a project. But it is essential that you plan, document, review, document, revise, document, then start programming.
In my opinion, 45% to 50% of a project's development duration should be spent in planning, designing and documenting. Not a single line of code should be written until you know exactly what you are doing. At that point coding is largely mechanical and trivial.
*** end of quote from Trimble ***

I would like to add that it makes a big difference whether you are designing and writing an application/ program for your own use versus for another user. If for a user, you need to get detailed requirements, especially for things like calculations to be done and any formulas required, date handling considerations, rounding methods to be used, etc.
*****

See, that's the beauty of a one-man development team using QB. There's no need to document anything more than essentials because I know the code like...well, nothing else. I put it all there, so I know it all by heart.

I just get right out and code. If I hit a wall or program myself into a corner, I do whatever I need to over. QB isn't serious enough a language to sit there and plan things through.

I, for one, don't do any paper planning. I usually nut things out in my mind first, and then sit down and begin coding, having found that expansion and bugfixing means that the development of the program soon outstrip the development and updating of the flowchart . Since I don't use QB that much anymore (I am learning C++), I modularise everything (very easy with C++) and just dive in.

Inevitably, poor design means that I have to rewrite. So I do. Then again. And again. Until my code is good enough to get a game out of (I mostly do crappy kinds of badly-optimised roguelike programming). Because it's so modularised and has little bits here and there, it's not too hard to add new features or remove and fix old ones.

This, of course, wouldn't work for any kind of professional or scientific programming, but it's good for me, as an entirely ameteur programmer.

For me, I usually just dive in the project. However, when the project gets larger I write my plans down on a piece of paper, or in notepad. E.g. I write tiles down, or some complex or heavy algorithms I want to use. I always modularize the whole project, so that I can easily do any extending or detending on the features.

When something fails in scripting, I start over again with the module. (you know, selecting and pressing Del... ). Anyway, when it works, it's good enough for me. When the project is done, or I come accross (speed) problems I then, and only then, go optimizing the code. When another bug is found, I just go debugging by putting PRINT's and SLEEP's everywhere...

For games:
I tend to write out all the major concepts first, then break down these concepts into what I like to call "project modules", or pieces I will do one step at a time (not always in order either). The fine details come at coding time for me, and I always keep a running list of dependencies either in my mind or in a .txt file.

For utilities:
Virtually all my utilities are written in VB6, which in and of itself lends the concept of "dev-on-the-fly". I rarely have to plan utility work ahead, and even when I do, it's only to break down major portions into more manageable pieces.

For both though...at least somewhat of a plan is formed before the code is begun. Games always require more work ahead of time because a game is a combination of many different types of program code, whereas a utility is a very specific program designed to assist another program (usually for me, it's to assist game creation!).