08-13-2005, 11:14 PM
Oracle,
I found an article by an old friend of mine, George R. Trimble, Jr., a giant in the computer industry. I think this article is pertinent to the discussion of having to resort to a dubugger.
I hope it becomes useful to you.
Regards,
Moneo
**************************************************
Development WorkBook (DWB)
by George R. Trimble, Jr.
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.
****************************************************
I found an article by an old friend of mine, George R. Trimble, Jr., a giant in the computer industry. I think this article is pertinent to the discussion of having to resort to a dubugger.
I hope it becomes useful to you.
Regards,
Moneo
**************************************************
Development WorkBook (DWB)
by George R. Trimble, Jr.
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.
****************************************************
