The Diagonal Development and Maintenance Method
In the navigation bar above, every Blue Box represents information. As a box darkens, click on the box to see its contents and its sub-pages
Diagonal Development and Maintenance Method
Some Person must do the Work.
There is no magic wand; there is no silver bullet, as Fred Brooks so correctly said many years ago. Patience, Ingenuity, Wisdom, Knowledge, Compassion and Good Practices make for good projects. People are the most important factor; good people make for easier projects; see Programmers A manager need not be effusive or gushy, but a manager should be capable of compassion; if the manager lacks people skills, then another person must assume that part of the role. The Agile Manifesto agrees with the Diagonal Method in many points. The Diagonal relies more on paradigms and restricts some of the choices for making decisions.
Maintenance and development go hand in hand. Good development greatly reduces maintenance. Good maintenance provides excellent paradigms for development. Once tools and function libraries are written, the team can re-deploy them over and over. Brooks asserted that adding people to a late project would make the project later. His projects contained late phase research and lacked paradigms and seemingly had black holes.
The name Diagonal Development and Maintenance Method (D2M2) comes from my father and my grandfathers. After my father married my mother, my father discovered that his father and his father-in-law followed similar methods for managing projects. All three of them used colored index cards on large blackboards to manage projects. As the components went thru their various stages, the diagonals of colored cards streamed across the board. See the diagram above.
The Team ! ! !
My father paid top dollar for top workers. He employed engineers, welders, electricians, concrete subcontractors, masons, and machinists. In every category, he had one or two highly proficient workers; those workers guided and trained other competent, energetic workers. Every two years or so, he and his crew re-built or re-modeled a large steel foundry. Belle City Malleable, Gunite in Rockford, J.I.Case, Wehr Steel, and others transformed under his touch. The unions were nervous until they realized that higher efficiencies often came with higher safety and much, much higher outputs; as output doubled, the foundry made more money and paid more workers higher wages. Some of the dad's workers were such long-time friends of my father, I was sad when one would move to a different job or stay behind when my father moved.
Every contract included clauses that required participation by senior management of the foundry. Though the overall timeline had been approved by the top management of the foundry, many day to day adjustments occurred. My father did not want to waste his time looking for a senior manager and then trying to explain the current situation; instead he wanted that person to live with the project. When my father and his crew moved on, the foundry had a well trained manager who knew the system and why design choices were made.
Similarly, a team can conquer software problems. A problem does not become a project until a manager does some investigation and organization. When working as a contractor, I have required a similar team. When working as an employee, I have asked for a similar team. For more details see Teams under Concepts and Practices
Stem to Stern Plan ! ! !
Every project requires a feasible plan. Most smaller projects have straight forward functional requirements. An informed designer who understands the requirements and understands the available tools and paradigms usually can form a skeleton in hours. Then comes the process of fleshing out the skeleton and of proving data flow. The designer needs to include all the necessary data fields and in the correct relationships. Usually some second person critiques the design. Sometimes for imports or exports, a person from the outside vendor helps assure feasibility. Often times, the outside vendor supplies source code to bridge the gap, which otherwise becomes a black hole. If possible black holes arise, some one researches or performs benchmarks. When black holes persist, the designer removes the black holes and re-considers the remaining functionality.
Specifications for manufacturing are plans, measurements, and tools.
Specifications for research are hopes, needs, and wants. A need usually is the justification for a manufacturing project, but a need is not a specification.
Larger projects often contain snarls and trade-offs. A snarl indicates some confusion about the specifications; a black hole by definition has no specification. Often IRS rules have snarls and the solution is to find an example that the IRS accepted. Parsing of natural language presents snarls, and often the solution is to handle specific known cases and then footnote the non-conforming phrases. All snarls either untangle or remain tangled. A tangled project might deserve more analysis as research but not as manufacturing.
Trade-offs exist throughout the realm of data processing.
As the questions under Lateral Thinking demonstrate, solving the correct problem is essential.
Where to do the work for trade-offs is strategic.
The plan must be understandable
If the plan is not comprehensible, chuck it and start over. Years ago, Rube Goldberg made fantastic machines in the cartoons, and the imagination was tickled by the feasibility. To flip a pancake, Rube might describe twenty steps including chickens, matches, mirrors, and bowling balls. The designer likewise must describe a plan that works; maybe the linkage between two systems is manual data entry. Not elegant and maybe not fast, but it is understandable. The point is the necessity of having a workable plan.
Without Completion, there is no ROI
The plan must finish in a timely manner. Thankfully today's machines are so fast and storage so plentiful that for business programming, solutions emerge easily. Well, maybe not always; Amazon, Google, and Alibaba pose volume challenges that are way beyond typical business processing. Trade-offs require prototypes and bench marks. For example, if the cash register program can handle ten thousand records per hour from a file, then the computational algorithms are fast enough for a human. Then the speed and ease of the screen becomes the question. At the Federated Group, sometimes a store system would go down and on the next day, a clerk would input all of the manual invoices. Such intense keying proved that a good clerk could do about 200 invoices an hour, which shows that the screens were plenty fast for normal usage.
Well, it does work
Some absurd manual linkages do exist. At General Motors about 1996, there was a manual data entry linkage between two systems. A programmer had to convert some hexadecimal numbers to decimal and then input them into a second program. It was not elegant or efficient. It was error prone and slow. It did work. The programmer added a run-time parameter to the program in the second system so that by default, the second program read the numbers from the binary repository of the first program. The conversion was only in the output representation. For those who wanted the manual method, they could change the value of the run-time parameter and revert to manual behavior.
Only Known Technologies ! ! ! ( NO BLACK HOLES )
My father refused to hope that any new technology would be ready by the end of a project. He wanted to build with confidence using known technologies. See Research or Manufacturing on Concepts and Practices This conservative and stubborn attitude is a major pillar of the Diagonal Method. When some optimistic person argues that a black hole can be solved during the project without affecting the timeline, turn the argument on its nose. Propose solving the black hold as the first phase of the project. Otherwise, split the project into two projects or three.
Paradigms ! ! !
This notion drives many managers to anger and others to skepticism. The designer should model every program and every process on an existing paradigm. Paradigms are the logical mirror image of known technologies. Not only does D2M2 avoid new technologies during manufacturing, D2M2 follows strict program design. At the Federated Group, the designer spent much time from February to the end of July building prototypes to solve black holes and paradigms to underpin the coming cash register project. Ergo: if there are no paradigms, build them first and build them carefully. In stark contrast, some organizations allow designers and programmers creative license.
Continual Correctness ! ! !
Every step and particularly every completion point should be subject to testing.
Frequent Installations ! ! !
As a program becomes functional , the installer should install it. This is a typical agile pillar. Usually an increase in functionality leads to an installation; sometimes several functions go better together. Installing early proves that the security and menus work. Installing early can bring early return on investment. For example, the inquiry power of the new screens was so versatile and fast, that having the inquiry improved the through-put of the office and increased acceptance by the users.
Return on Investment ! ! !
Either the project should be essential to the organization or the project should have a high return on investment. Otherwise, the project lacks benefit to the organization. The cash register at the Federated Group was essential and had an extreme ROI Also its error checking and its credit checking helped to avoid scams. A data mining project that identified trends of high spending customers had a high ROI. Having the team members aware of the need for ROI tends to improve productivity. After an organization becomes profitable, maybe it can afford a few non-essential, non-profitable projects. Some research projects end as failures; such is the nature of research; research often lacks ROI. A visionary might predict that a certain feature could fuel sales or save costs; that visionary should have sufficient rank to take that risk.
ROI per Time
Both Amazon and FedEx needed years to become profitable. Their backers suffered thru years of losses. Most business have no such sugar daddy, More likely, the business has less than six months of reserve, Summary: projects must complete within budget and on time.
No ROI
On the other hand, the chain of Treasury Stores went bankrupt when its cash registers became so slow that customers avoided the stores, particularly during the noon time lunch hour. The threat to the shopper was being stuck in line and thus being late going back to work. Alltime Stores went bankrupt when its computer system could not handle transactions for a day within one day. Blue Cross of California almost suffered the same demise until a brave VP was willing to alter the indexing that was recommended by Oracle; a simple decrease in the records per leaf sped up the processing several fold.
The preceding concepts, marked by !!!, are the pillars of the Diagonal Method
The following are ideas and consequences
==========
Size and Scope verses the Diagonal Method
Friends of mine at Northrop Grumman, at Microsoft, and at Google have tried to describe the complexity of some of their projects. Enormous with thousands of circuits. More inquiries per hour that exceed a year of processing at my businesses in my experience. My methods probably would not work. Nevertheless, little Alltime did 30 transactions per day per store, which is 9,000 per day or 63,000 per week. The Group did some 400 per store times 80 stores per day, which is 32,000, and those usually affect more than a dozen records. The Diagonal method worked happily there. Herbalife and Pic'n'Save had even higher volumes. Herbalife had seven large HP3000s chugging along seven days per week; a little process management went a long way. At the low end, a college with 10,000 students generates far fewer transactions per year and its business cycle is monthly or semester based.
The Last Shall be First
The typical foundry has production stages: molding, melting, pouring, grinding, finishing, and shipping. Much to the surprise of the managers at the foundries--at least those who had not hired him, my father often started in the shipping department. His reasoning was simple; if the first stages increased faster than finishing, bottlenecks would cause problems. His plan was to complete the stages in reverse order. Artfully in the shipping department, he usually found new space to install the new equipment and then progressively replaced shipping stations so that shipping never went down. After shipping was done or nearly done, he re-modeled finishing and so on back to molding. Actually, melting required a blast furnace, which can take a year or more to build, so the overall process completed in reverse order. Again by good planning, he would attempt to locate the first new furnace in a manner that would avoid interruptions to production. Many foundries took two weeks off in July; sometimes that break could be tactically located within the development schedule.
In software projects, the typically last steps should be done first. If you have seen many projects done by different managers, then you have probably seen menu positions, security, and permissions done late in the project. Often the first immigration to production occurs late in the project; the normal mental process of envisioning a project places migration at the end of the project. Under D2M2, these tasks should come near the front of the project and migrations occur early and often. Consider the advantage of migrating some simple prototypes early in the project.
The programmers make a prototype. The sysadmins or other security persons implement security and set up the clerks and install the prototype. Then the clerks logon and the security itself hopefully passes. If the security fails, then there is plenty of time to recover. The clerks can also begin giving feedback about the prototypes. As the project progresses, the sysadmins re-install the programs. By the completion of the project, the menu, the security and the installation have been operating for a long time.
Prototypes and Paradigms
In most shops, there are few formal paradigms. Paradigms are programs which the manager of the shop has designated as strict models for new programs. Hopefully, the programmers and designers agree on the paradigms. In a shop with paradigms, as the shop matures, most programs change towards conformity to the paradigms, and each prototype comes directly from a paradigm. With a really strong practice of having paradigms, the prototype is a paradigm with many features turned off.
At Builder's Brass, the uniformity of programs decreased the learning curve. At the Federated Group, several large projects used paradigms as part of the specifications. Specs for a report included reference to one of the several paradigms, which ranged from a simple listing, to control breaks, to dynamic control breaks, to complex with multiple outputs, and several document printers. Programming became a manufacturing exercise. In a simpler view, a manager who is highly aware of his software makes suggestions that a new program should mimic an existing program. The advantage of the paradigms is that nearly all of the algorithms are predefined; the time to modify is a small fraction of the time to create. See Paradigm Inventory xxx
Incremental Progress
As the prototype grows as new functions turn on, the sysadmins re-install the program. The clerks re-test. If the results are good, the project flows forward. If errors appear, then most likely the cause in the most recent code. Having a smaller search area should expedite the fix.
A ten lane bridge is a little like incremental progress; first one lane opens and then another and another. But the lanes on the bridge are too much alike. The functions in a program can be very different. Maybe the first one does look-ups. Maybe the second one prints. The third accepts some input.
Strategic Scaffolding
As the project progresses, the programmers need confirmation of correctness. During the IFAS installation at APU, we implemented the Month End Reports as we imported records from the old accounting system. The month end reports showed us that the totals in the new system matched the totals in the old system. We could have done totals some other way, but this way implemented a required component and showed correctness. Similarly, when programs require data which then is destroyed, it is strategic to have scaffolding that re-initializes the data.
Early Return on Investment
Thorough examination of the project, especially large projects, usually reveals some isolated functional parts that become candidates for early return on investment. Sometimes the functionality is an inquiry into the data or into a remote service. Connecting to the remote service also has the effect of handling an external service early in the project. Programs that print labels are another candidate for ROI. The program that prints the major document, such as purchase order or invoice, is another good candidate. A good SQL script loads the data and the program displays the document. Once printing works, the document becomes useful for proving correctness. Depending how data feeds the program, some early implementation might allow early use of the new format.
External Resource and Requirements
Wherever the project receives data from an external source or wherever it exports data to an external source, the manager should coordinate with those resources earlier than later. This is also true of telephones, licenses, government certifications, and xxx. Buying equipment can present risks, as can relying on negotiations. In worse cases, the external organization requires a reservation to perform testing.
It Works or It Does Not
Every program should have significant measurable milestones. When programs grow from paradigms, the milestones are well known and should be easy to achieve. Good designs reveal good milestones. By those who do not understand the manufacturing nature of projects, but rather confuse manufacturing and research, also somehow make claims about programming being creative. Never allow a programmer to measure progress as a percentage of completion; 80% done is impending failure. Rather, count milestones.
Tactical Attack
Can at least one entire pathway thru the process be completed by manual means? Is there some sequence of steps that demonstrate completeness. If the answer is negative, the project is in trouble. If the answer is positive, the pathway presents a possible good avenue for inital work.
First Editions
Incremental progress applies to programs; the first edition applies to the entire stem to stern process that the project implements. Again, early releases allow the customer to evaluate the success and to give guidance. First editions also help to verify the implementation methods.
Unsung Heroes
Maintenance programmers receive little praise, but in many shops, maintenance requires more effort than development. A good maintenance programmer steadily improves the overall quality of the software. The programmer makes the changes required by the current request and also considers any on-going campaigns.
Collateral Repair
Every time a major program requires maintenance, the programmer should also consider any pending campaigns to overhaul the entire body of software. A campaign is an activity that requires touching all the software for a large system. Converting from RPG to QUIZ was such a campaign. Installing logging into every batch job was such a campaign. In another example, one manufacturer wanted every screen to display information about itself when the clerk pressed ctrl-J. After first perfecting the steps to implement, the programmers stuck the new routines and objects into each program that required changes because of standard business changes. On Fridays, some programmers attacked their favorite modules.
Ever Improving
At UC-Irvine, the professors taught a wonderful mix of hands-on compiler writing and mathematical theory. The theory prescribed methods for solving problems. The compilers, network travelers, parsers, real-time games, and artificial intelligence tasks gave the students very sharp skills.
Quality verses Quantity
Good design eliminates some of the need for subsequent modification of source code. see xxx
.
.
Some Person must do the Work.
There is no magic wand; there is no silver bullet, as Fred Brooks so correctly said many years ago. Patience, Ingenuity, Wisdom, Knowledge, Compassion and Good Practices make for good projects. People are the most important factor; good people make for easier projects; see Programmers A manager need not be effusive or gushy, but a manager should be capable of compassion; if the manager lacks people skills, then another person must assume that part of the role. The Agile Manifesto agrees with the Diagonal Method in many points. The Diagonal relies more on paradigms and restricts some of the choices for making decisions.
Maintenance and development go hand in hand. Good development greatly reduces maintenance. Good maintenance provides excellent paradigms for development. Once tools and function libraries are written, the team can re-deploy them over and over. Brooks asserted that adding people to a late project would make the project later. His projects contained late phase research and lacked paradigms and seemingly had black holes.
The name Diagonal Development and Maintenance Method (D2M2) comes from my father and my grandfathers. After my father married my mother, my father discovered that his father and his father-in-law followed similar methods for managing projects. All three of them used colored index cards on large blackboards to manage projects. As the components went thru their various stages, the diagonals of colored cards streamed across the board. See the diagram above.
The Team ! ! !
My father paid top dollar for top workers. He employed engineers, welders, electricians, concrete subcontractors, masons, and machinists. In every category, he had one or two highly proficient workers; those workers guided and trained other competent, energetic workers. Every two years or so, he and his crew re-built or re-modeled a large steel foundry. Belle City Malleable, Gunite in Rockford, J.I.Case, Wehr Steel, and others transformed under his touch. The unions were nervous until they realized that higher efficiencies often came with higher safety and much, much higher outputs; as output doubled, the foundry made more money and paid more workers higher wages. Some of the dad's workers were such long-time friends of my father, I was sad when one would move to a different job or stay behind when my father moved.
Every contract included clauses that required participation by senior management of the foundry. Though the overall timeline had been approved by the top management of the foundry, many day to day adjustments occurred. My father did not want to waste his time looking for a senior manager and then trying to explain the current situation; instead he wanted that person to live with the project. When my father and his crew moved on, the foundry had a well trained manager who knew the system and why design choices were made.
Similarly, a team can conquer software problems. A problem does not become a project until a manager does some investigation and organization. When working as a contractor, I have required a similar team. When working as an employee, I have asked for a similar team. For more details see Teams under Concepts and Practices
Stem to Stern Plan ! ! !
Every project requires a feasible plan. Most smaller projects have straight forward functional requirements. An informed designer who understands the requirements and understands the available tools and paradigms usually can form a skeleton in hours. Then comes the process of fleshing out the skeleton and of proving data flow. The designer needs to include all the necessary data fields and in the correct relationships. Usually some second person critiques the design. Sometimes for imports or exports, a person from the outside vendor helps assure feasibility. Often times, the outside vendor supplies source code to bridge the gap, which otherwise becomes a black hole. If possible black holes arise, some one researches or performs benchmarks. When black holes persist, the designer removes the black holes and re-considers the remaining functionality.
Specifications for manufacturing are plans, measurements, and tools.
Specifications for research are hopes, needs, and wants. A need usually is the justification for a manufacturing project, but a need is not a specification.
Larger projects often contain snarls and trade-offs. A snarl indicates some confusion about the specifications; a black hole by definition has no specification. Often IRS rules have snarls and the solution is to find an example that the IRS accepted. Parsing of natural language presents snarls, and often the solution is to handle specific known cases and then footnote the non-conforming phrases. All snarls either untangle or remain tangled. A tangled project might deserve more analysis as research but not as manufacturing.
Trade-offs exist throughout the realm of data processing.
- The bandwidth of a network verses the cost of faster hardware is a trade-off.
- On personal computers, the number of start-up processes verses time to start-up.
- When a clerk rarely opens a local database, then why initialize the database during start-up.
- Should we pre-compute index values or compute when the clerk asks?
- How much internet access is enough, and how much time is wasted surfing?
- The design of programs can generate great controversy about style, speed, and complexity.
As the questions under Lateral Thinking demonstrate, solving the correct problem is essential.
Where to do the work for trade-offs is strategic.
The plan must be understandable
If the plan is not comprehensible, chuck it and start over. Years ago, Rube Goldberg made fantastic machines in the cartoons, and the imagination was tickled by the feasibility. To flip a pancake, Rube might describe twenty steps including chickens, matches, mirrors, and bowling balls. The designer likewise must describe a plan that works; maybe the linkage between two systems is manual data entry. Not elegant and maybe not fast, but it is understandable. The point is the necessity of having a workable plan.
Without Completion, there is no ROI
The plan must finish in a timely manner. Thankfully today's machines are so fast and storage so plentiful that for business programming, solutions emerge easily. Well, maybe not always; Amazon, Google, and Alibaba pose volume challenges that are way beyond typical business processing. Trade-offs require prototypes and bench marks. For example, if the cash register program can handle ten thousand records per hour from a file, then the computational algorithms are fast enough for a human. Then the speed and ease of the screen becomes the question. At the Federated Group, sometimes a store system would go down and on the next day, a clerk would input all of the manual invoices. Such intense keying proved that a good clerk could do about 200 invoices an hour, which shows that the screens were plenty fast for normal usage.
Well, it does work
Some absurd manual linkages do exist. At General Motors about 1996, there was a manual data entry linkage between two systems. A programmer had to convert some hexadecimal numbers to decimal and then input them into a second program. It was not elegant or efficient. It was error prone and slow. It did work. The programmer added a run-time parameter to the program in the second system so that by default, the second program read the numbers from the binary repository of the first program. The conversion was only in the output representation. For those who wanted the manual method, they could change the value of the run-time parameter and revert to manual behavior.
Only Known Technologies ! ! ! ( NO BLACK HOLES )
My father refused to hope that any new technology would be ready by the end of a project. He wanted to build with confidence using known technologies. See Research or Manufacturing on Concepts and Practices This conservative and stubborn attitude is a major pillar of the Diagonal Method. When some optimistic person argues that a black hole can be solved during the project without affecting the timeline, turn the argument on its nose. Propose solving the black hold as the first phase of the project. Otherwise, split the project into two projects or three.
- the first project has focus on the black hole
- the second relies on the features of the first and so the second should wait until the first completes
- the third proceeds without the benefit of the first; if the third has no value without the first, then it also should wait
- or, do two projects if the project with full specs has value or merit; let the project with the black hole proceed as research.
Paradigms ! ! !
This notion drives many managers to anger and others to skepticism. The designer should model every program and every process on an existing paradigm. Paradigms are the logical mirror image of known technologies. Not only does D2M2 avoid new technologies during manufacturing, D2M2 follows strict program design. At the Federated Group, the designer spent much time from February to the end of July building prototypes to solve black holes and paradigms to underpin the coming cash register project. Ergo: if there are no paradigms, build them first and build them carefully. In stark contrast, some organizations allow designers and programmers creative license.
Continual Correctness ! ! !
Every step and particularly every completion point should be subject to testing.
Frequent Installations ! ! !
As a program becomes functional , the installer should install it. This is a typical agile pillar. Usually an increase in functionality leads to an installation; sometimes several functions go better together. Installing early proves that the security and menus work. Installing early can bring early return on investment. For example, the inquiry power of the new screens was so versatile and fast, that having the inquiry improved the through-put of the office and increased acceptance by the users.
Return on Investment ! ! !
Either the project should be essential to the organization or the project should have a high return on investment. Otherwise, the project lacks benefit to the organization. The cash register at the Federated Group was essential and had an extreme ROI Also its error checking and its credit checking helped to avoid scams. A data mining project that identified trends of high spending customers had a high ROI. Having the team members aware of the need for ROI tends to improve productivity. After an organization becomes profitable, maybe it can afford a few non-essential, non-profitable projects. Some research projects end as failures; such is the nature of research; research often lacks ROI. A visionary might predict that a certain feature could fuel sales or save costs; that visionary should have sufficient rank to take that risk.
ROI per Time
Both Amazon and FedEx needed years to become profitable. Their backers suffered thru years of losses. Most business have no such sugar daddy, More likely, the business has less than six months of reserve, Summary: projects must complete within budget and on time.
No ROI
On the other hand, the chain of Treasury Stores went bankrupt when its cash registers became so slow that customers avoided the stores, particularly during the noon time lunch hour. The threat to the shopper was being stuck in line and thus being late going back to work. Alltime Stores went bankrupt when its computer system could not handle transactions for a day within one day. Blue Cross of California almost suffered the same demise until a brave VP was willing to alter the indexing that was recommended by Oracle; a simple decrease in the records per leaf sped up the processing several fold.
The preceding concepts, marked by !!!, are the pillars of the Diagonal Method
The following are ideas and consequences
==========
Size and Scope verses the Diagonal Method
Friends of mine at Northrop Grumman, at Microsoft, and at Google have tried to describe the complexity of some of their projects. Enormous with thousands of circuits. More inquiries per hour that exceed a year of processing at my businesses in my experience. My methods probably would not work. Nevertheless, little Alltime did 30 transactions per day per store, which is 9,000 per day or 63,000 per week. The Group did some 400 per store times 80 stores per day, which is 32,000, and those usually affect more than a dozen records. The Diagonal method worked happily there. Herbalife and Pic'n'Save had even higher volumes. Herbalife had seven large HP3000s chugging along seven days per week; a little process management went a long way. At the low end, a college with 10,000 students generates far fewer transactions per year and its business cycle is monthly or semester based.
The Last Shall be First
The typical foundry has production stages: molding, melting, pouring, grinding, finishing, and shipping. Much to the surprise of the managers at the foundries--at least those who had not hired him, my father often started in the shipping department. His reasoning was simple; if the first stages increased faster than finishing, bottlenecks would cause problems. His plan was to complete the stages in reverse order. Artfully in the shipping department, he usually found new space to install the new equipment and then progressively replaced shipping stations so that shipping never went down. After shipping was done or nearly done, he re-modeled finishing and so on back to molding. Actually, melting required a blast furnace, which can take a year or more to build, so the overall process completed in reverse order. Again by good planning, he would attempt to locate the first new furnace in a manner that would avoid interruptions to production. Many foundries took two weeks off in July; sometimes that break could be tactically located within the development schedule.
In software projects, the typically last steps should be done first. If you have seen many projects done by different managers, then you have probably seen menu positions, security, and permissions done late in the project. Often the first immigration to production occurs late in the project; the normal mental process of envisioning a project places migration at the end of the project. Under D2M2, these tasks should come near the front of the project and migrations occur early and often. Consider the advantage of migrating some simple prototypes early in the project.
The programmers make a prototype. The sysadmins or other security persons implement security and set up the clerks and install the prototype. Then the clerks logon and the security itself hopefully passes. If the security fails, then there is plenty of time to recover. The clerks can also begin giving feedback about the prototypes. As the project progresses, the sysadmins re-install the programs. By the completion of the project, the menu, the security and the installation have been operating for a long time.
Prototypes and Paradigms
In most shops, there are few formal paradigms. Paradigms are programs which the manager of the shop has designated as strict models for new programs. Hopefully, the programmers and designers agree on the paradigms. In a shop with paradigms, as the shop matures, most programs change towards conformity to the paradigms, and each prototype comes directly from a paradigm. With a really strong practice of having paradigms, the prototype is a paradigm with many features turned off.
At Builder's Brass, the uniformity of programs decreased the learning curve. At the Federated Group, several large projects used paradigms as part of the specifications. Specs for a report included reference to one of the several paradigms, which ranged from a simple listing, to control breaks, to dynamic control breaks, to complex with multiple outputs, and several document printers. Programming became a manufacturing exercise. In a simpler view, a manager who is highly aware of his software makes suggestions that a new program should mimic an existing program. The advantage of the paradigms is that nearly all of the algorithms are predefined; the time to modify is a small fraction of the time to create. See Paradigm Inventory xxx
Incremental Progress
As the prototype grows as new functions turn on, the sysadmins re-install the program. The clerks re-test. If the results are good, the project flows forward. If errors appear, then most likely the cause in the most recent code. Having a smaller search area should expedite the fix.
A ten lane bridge is a little like incremental progress; first one lane opens and then another and another. But the lanes on the bridge are too much alike. The functions in a program can be very different. Maybe the first one does look-ups. Maybe the second one prints. The third accepts some input.
Strategic Scaffolding
As the project progresses, the programmers need confirmation of correctness. During the IFAS installation at APU, we implemented the Month End Reports as we imported records from the old accounting system. The month end reports showed us that the totals in the new system matched the totals in the old system. We could have done totals some other way, but this way implemented a required component and showed correctness. Similarly, when programs require data which then is destroyed, it is strategic to have scaffolding that re-initializes the data.
Early Return on Investment
Thorough examination of the project, especially large projects, usually reveals some isolated functional parts that become candidates for early return on investment. Sometimes the functionality is an inquiry into the data or into a remote service. Connecting to the remote service also has the effect of handling an external service early in the project. Programs that print labels are another candidate for ROI. The program that prints the major document, such as purchase order or invoice, is another good candidate. A good SQL script loads the data and the program displays the document. Once printing works, the document becomes useful for proving correctness. Depending how data feeds the program, some early implementation might allow early use of the new format.
External Resource and Requirements
Wherever the project receives data from an external source or wherever it exports data to an external source, the manager should coordinate with those resources earlier than later. This is also true of telephones, licenses, government certifications, and xxx. Buying equipment can present risks, as can relying on negotiations. In worse cases, the external organization requires a reservation to perform testing.
It Works or It Does Not
Every program should have significant measurable milestones. When programs grow from paradigms, the milestones are well known and should be easy to achieve. Good designs reveal good milestones. By those who do not understand the manufacturing nature of projects, but rather confuse manufacturing and research, also somehow make claims about programming being creative. Never allow a programmer to measure progress as a percentage of completion; 80% done is impending failure. Rather, count milestones.
Tactical Attack
Can at least one entire pathway thru the process be completed by manual means? Is there some sequence of steps that demonstrate completeness. If the answer is negative, the project is in trouble. If the answer is positive, the pathway presents a possible good avenue for inital work.
First Editions
Incremental progress applies to programs; the first edition applies to the entire stem to stern process that the project implements. Again, early releases allow the customer to evaluate the success and to give guidance. First editions also help to verify the implementation methods.
Unsung Heroes
Maintenance programmers receive little praise, but in many shops, maintenance requires more effort than development. A good maintenance programmer steadily improves the overall quality of the software. The programmer makes the changes required by the current request and also considers any on-going campaigns.
Collateral Repair
Every time a major program requires maintenance, the programmer should also consider any pending campaigns to overhaul the entire body of software. A campaign is an activity that requires touching all the software for a large system. Converting from RPG to QUIZ was such a campaign. Installing logging into every batch job was such a campaign. In another example, one manufacturer wanted every screen to display information about itself when the clerk pressed ctrl-J. After first perfecting the steps to implement, the programmers stuck the new routines and objects into each program that required changes because of standard business changes. On Fridays, some programmers attacked their favorite modules.
Ever Improving
At UC-Irvine, the professors taught a wonderful mix of hands-on compiler writing and mathematical theory. The theory prescribed methods for solving problems. The compilers, network travelers, parsers, real-time games, and artificial intelligence tasks gave the students very sharp skills.
Quality verses Quantity
Good design eliminates some of the need for subsequent modification of source code. see xxx
.
.