My first job was with an investment bank on Wall Street. It was before there were PCs and spreadsheets. Most front-office computing was done through expensive time-sharing systems, using subscription-only databases of financial information. The dominant language was FORTRAN, a primitive development platform by today's standards, but simple, fast and strong with heavy duty calculations. Each analysis case often required its own program. What-if scenarios meant changing and recompiling a program.
It did not take long for me to realize one of the fundamental rules of computer programming: only do something the long way once. You could write FORTRAN programs two ways: as one big program, or as a string of smaller programs. The latter meant developing subroutines and functions to do simple or specific tasks as components in a larger program. As I developed more applications, I wanted to reuse as many of these subroutines as possible. It was faster, easier, and less boring to string together some predefined and tested components than starting from scratch again. In a year, I was able to develop systems in less than half the time, with half the coding and testing. My library of FORTRAN subroutines was my prized toolkit.
What I realized years later was that I was developing a set of components, or objects in today's lingo. These were like predefined Lego components that could be added to other components to create a new toy. I learned at the very beginning just how important small modules were for creating computer programs. I also learned that most complex and complicated problems can be broken down into simpler parts. More importantly, most new problems at least in part are recycled old problems. |