Research Projects within the Diagonal Method
How are We going to do This Request?
Regularly the manager and his programmers must do simple research. In business programming, at which the Diagonal Method works well, the number of new features has occasional spurts. Once the system has stabilizes, a certain rhythm sets in. Research projects usually take requests and match them to paradigms and plans. Some requests become multiple tasks.
Unrealistic Estimates
The unknown nature of research projects discourages precise scheduling that would be based on completion. The more obscure or the more extreme the nature of the problem, the less likely an honest estimate exists. A manager could make a bloated estimate but not a precise estimate for time until completion. Some research projects like mathematical theorems have remained unsolved for years. Fermat posed his now 'Lost' theorem more than 200 years ago. Consequently, the director and the manager gather information, consider various experiments and strategies, and then allocate chunks of time. More understanding of the uncertain natural of research shows that no person knows for sure how long research will take. Instead, the manager matches up experiments and willing workers.
Try Solving this in Two Weeks
More typically and more practically, the manager gives the willing workers, who now act as researchers, a given amount of time to solve the problem. If the workers find a solution, then every one celebrates. Other times, the workers can show the likelihood of a solution, and allocating more time makes sense. For example, time has expired but some part of the problem has been solved. In communicating with a radio transmitter/receiver, a week of effort went from no responses to error messages that appeared in the documentation. Another week of work combined with information derived from the error messages led to a working solution.
Cut the Problem in Two
In a more common situation, an organization was trying to talk in real time to a commercial bank. The tech department at the bank had sent COBOL code to the team. The team translated the COBOL into Perl, but the Perl produced no results The team put a sniffer where the outgoing signal left the organization's internal network. This split the problem in two. The sniffer could ping the bank and the bank could see the ping. The organization's own firewall turned out to be the impediment; the system admins had turned off a certain protocol as being unneeded. The Perl routines handles some of the transaction. Finally, the bank clarified by example the last few transactions and the programmers had to adjust the Perl. The techs at the bank had stated that most customers connect in a week or two.
Never in a Zillion Years
In making the Peoplesoft program pside run in batch mode to perform mass backups, two errors hindered success, The programmers tried parttime for a week. They looked at earlier versions that did run. Finally they called Oracle, and they got the usual run-around. "Why would you want to do that?" "I am not familiar with that; let me hand you off to some one else." "It worked on the previous version," The programmers dropped the project and put focus on other projects. About ten days later, an expert from Oracle called and reported one of the twenty some parameters required a change under the new version. Immediately, the pside program began to work. Then the programmers discovered that they had interpreted a file specification incorrectly. After fixing the spec, the program performed beautifully. Finding the Oracle bug would have been next to impossible for the programmers; who would ever guess that changing from one seemingly valid format to another would be the bug. If the source code was available, then yes, but it is unlikely to get source code from Oracle.
Failure leads to Re-Evaluation
Black Holes can consume an infinite amount of time, energy, mass, and light. Almost by definition, an organization should expect some research projects to fail at least at first. Each effort takes time and money. The lack of return on investment becomes a factor. Maybe the programmers realize that they lack knowledge and cannot write a solution; they surrender and agree that buying a solution might be better. Other times, the manager already has another planned experiment. History says that Thomas Edison had numerous failures before perfecting his first light bulb. In other cases, the manager abandons the research
Beg, Borrow, Buy, or Abandon
The romantic vision is that some researcher invents an algorithm, that some programmer creates a solution. In rare cases, a true invention does occur. More often, a wise researcher remembers a similar problem and adapts the older solution to the new solution. Or like the bank scenario above, the researchers copy from a working solution. In other pragmatic situations, the manager hires an expert or buys a service. In the lowest case, the effort fails and the manager must re-evaluate the options.
Regularly the manager and his programmers must do simple research. In business programming, at which the Diagonal Method works well, the number of new features has occasional spurts. Once the system has stabilizes, a certain rhythm sets in. Research projects usually take requests and match them to paradigms and plans. Some requests become multiple tasks.
Unrealistic Estimates
The unknown nature of research projects discourages precise scheduling that would be based on completion. The more obscure or the more extreme the nature of the problem, the less likely an honest estimate exists. A manager could make a bloated estimate but not a precise estimate for time until completion. Some research projects like mathematical theorems have remained unsolved for years. Fermat posed his now 'Lost' theorem more than 200 years ago. Consequently, the director and the manager gather information, consider various experiments and strategies, and then allocate chunks of time. More understanding of the uncertain natural of research shows that no person knows for sure how long research will take. Instead, the manager matches up experiments and willing workers.
Try Solving this in Two Weeks
More typically and more practically, the manager gives the willing workers, who now act as researchers, a given amount of time to solve the problem. If the workers find a solution, then every one celebrates. Other times, the workers can show the likelihood of a solution, and allocating more time makes sense. For example, time has expired but some part of the problem has been solved. In communicating with a radio transmitter/receiver, a week of effort went from no responses to error messages that appeared in the documentation. Another week of work combined with information derived from the error messages led to a working solution.
Cut the Problem in Two
In a more common situation, an organization was trying to talk in real time to a commercial bank. The tech department at the bank had sent COBOL code to the team. The team translated the COBOL into Perl, but the Perl produced no results The team put a sniffer where the outgoing signal left the organization's internal network. This split the problem in two. The sniffer could ping the bank and the bank could see the ping. The organization's own firewall turned out to be the impediment; the system admins had turned off a certain protocol as being unneeded. The Perl routines handles some of the transaction. Finally, the bank clarified by example the last few transactions and the programmers had to adjust the Perl. The techs at the bank had stated that most customers connect in a week or two.
Never in a Zillion Years
In making the Peoplesoft program pside run in batch mode to perform mass backups, two errors hindered success, The programmers tried parttime for a week. They looked at earlier versions that did run. Finally they called Oracle, and they got the usual run-around. "Why would you want to do that?" "I am not familiar with that; let me hand you off to some one else." "It worked on the previous version," The programmers dropped the project and put focus on other projects. About ten days later, an expert from Oracle called and reported one of the twenty some parameters required a change under the new version. Immediately, the pside program began to work. Then the programmers discovered that they had interpreted a file specification incorrectly. After fixing the spec, the program performed beautifully. Finding the Oracle bug would have been next to impossible for the programmers; who would ever guess that changing from one seemingly valid format to another would be the bug. If the source code was available, then yes, but it is unlikely to get source code from Oracle.
Failure leads to Re-Evaluation
Black Holes can consume an infinite amount of time, energy, mass, and light. Almost by definition, an organization should expect some research projects to fail at least at first. Each effort takes time and money. The lack of return on investment becomes a factor. Maybe the programmers realize that they lack knowledge and cannot write a solution; they surrender and agree that buying a solution might be better. Other times, the manager already has another planned experiment. History says that Thomas Edison had numerous failures before perfecting his first light bulb. In other cases, the manager abandons the research
Beg, Borrow, Buy, or Abandon
The romantic vision is that some researcher invents an algorithm, that some programmer creates a solution. In rare cases, a true invention does occur. More often, a wise researcher remembers a similar problem and adapts the older solution to the new solution. Or like the bank scenario above, the researchers copy from a working solution. In other pragmatic situations, the manager hires an expert or buys a service. In the lowest case, the effort fails and the manager must re-evaluate the options.