There are good, as well as bad experiences. Was hired to join a programming team in the R&D lab of a major oil company. The project was a global mapping program. Project leader was about to be transferred to a bigger project, and they needed an old card thumper to churn out code. They were about half way to version one when I arrived.
We were very well organized. Design was carefully planned, fully documented. Programming was top-down. We met each morning an hour before coffee break, reviewed the code from the previous day that had been tested by one of us, both for accuracy and for conforming to our standards for how variables were to be named, etc. Then, after coffee, we designed the next routine or two in a simplified code we called pidgin. These were farmed out to members to the team to finish, punch, and test with dummy data and a throw-away calling routine. We also tested algorithms with private code. We could look at a variable name in the code and see at a glance what type and size it was, and whether it was global or local. We had a table of global variables and exactly what they were, down to units and valid ranges of values. A beginner could do maintenance on such a program with ease. I worked out, for example, a simple but accurate approximation for including deviations of the earth from the sphere in any projection and arbitrary orientation of axes, which we knew we would need sometime. When the time came, I was no longer with that project, but my memo to files was enough to show how to implement it in a week or so, in time to use it to meet a contract deadline. Worst case error was a couple of meters with respect to exact formula in special cases we could test. Saved hundreds of machine hours on a cluster of IBM's biggest and best doing great circle seismic lines for offshore somewhere in Asia. By the time version one was released, we had a card cabinet of source code. No subroutine was more than two pages long, and none had more than one functional purpose. Hooks were left with stubs for what was yet to be implemented. I added magnetic anomaly data in one day, using similar code as templates, adding a whole tree. The program sorted through data bases for selected data that fitted into the map area, defined by latitude and longitudes of points on great circles. We were doing plate tectonic modeling, so we had routines to turn back the geological clock on plate motions, etc. When we released version one, we had a dozen or so known bugs to be fixed in version two, and a shopping list of things our internal customers wanted added. Between versions the project went from punched cards to interactive, discovering a number of changes that had to be made in code management for that. We did a first test with dummy data and a calling routine that was to be discarded. When we were ready to add that routine to the working program, we replaced the stub or dummy with the new routine and any stubs it needed. We had to test the combination without permanently changing the full program, which would be in use as well as used with different new routines being tested by others. We got through version one without confusion of the what was part of the accepted code and what was being tested. I enjoy the planning and organization of very large programming projects. Makes me almost regret being retired. I do think it was easier to keep track of what we were doing in FORTRAN than in less reader friendly languages. We did have some rules..... Choppy At 09:01 AM 1/17/05 -0600, Craig Banker wrote: >Quick question to the fellow coders out there... > > >What do you do to bring yourself up to speed on complex coding projects? > >This one is very pertinant to those who want to contribute effort to open >source projects... > >Anybody care to share some insight or battle stories, perhaps?
