Grid Programming

I found this quote in a book related to Grid Design - the new step on systems design:
"Grid programming, by the very nature of the Grid, will confound definition, likely for years to come. Because the Grid can be many things to many people, the people making the definitions will, by defining what they put on the Grid, play a part in defining the programming paradigm that goes along with that Grid.

One definition, however, is likely to carry through many different threads. Whatever paradigm and whatever programming language or languages rise to meet the Grid challenge, modularity will have to play a large part in the definition.

Modularity, as discussed, leads to smaller programs that are easier to read, write, debug, and maintain. These self-contained functions and procedures can be stored in libraries to be used and reused by other programs and even other languages, depending on how they are written and called.

Modular programs are easier to write and test because each individual component can be written independently and tested thoroughly with minimal effort and time spent on each step. Thought should be given to the logic behind the program and to the way that other programs will interact with it, and concentration can be dedicated to a very discrete problem (often either a business problem or a known programming problem).

Moreover, smaller modules are more easily read and debugged because no extensive sections of code are involved in the overall program as a whole, but rather stored in the smaller subprograms. Reading through discrete amounts of code is simpler and more elegant. Testing the code in each module is quicker, and less code means fewer places that errors can occur. In addition, the testing of the overall program is easier and the programs can be handed off with more confidence because the testing has occurred at many different levels and testing the overall logic may only mean testing the logic of the flow rather than having to test and retest the logic at every step in the code.

The modularity will lead to more robust code modules and function and procedure reuse. Once a module is found to be sound and accurate for computing averages, that code can be used anywhere that a series of numbers needs to be averaged. Another module can be used to compute standard deviation, another return on investment, and another internal rate of return. By making a module that reliably computes a single function, and making it once very well, attention can be paid to less mundane programming challenges. Modular programming does not necessarily have to be associated with object-oriented programming design — however, it often is."

It looks like the architecture we used to develop the Unattended Oracle Installation was based on this concept and maybe this is the reason why it was a great success: Solid knowledge of the project (Things to do) and good design and methodology.

Nimio Cabello

Database Architect

Siemens Energy & Automation, Inc.