I was reviewing a code for a web site I created in 1997 which led me to think about what it was like at the time. The website, the campus-wide calendar of events (http://events.sa.ucsb.edu/), was one of the very first campus-wide web application at UCSB. In reviewing the code, it came to me that codes are artifacts in themselves, revealing not only how the application was developed as well as developers’ environment and abilities. With further investigation, codes do lead to some revelations about the politics, the technologies, the state of the organization at that time as well. In a way, the code in itself has a culture behind it.
One of the common reactions from developers who have the opportunity/responsibility to maintain/adjust code is to criticize how the application was created and the technology used. I have to admit that I also cringe when I review my code. However, given the technical tools available, my personal ability and the politics of the organization at that time, that was the best I could have produced. If I knew any better and my environment allowed me to produce something better, I would have certainly done so.
During those times when my developers start complaining about having to re-write my spaghetti code and old technology, I used to take the comments personally and become defensive but in the last few years, I’ve taken the opportunity to discuss the history of our organization, the people and the history of web computing at UCSB. Some of the stories I’ve told that happened during that period include the following:
* Active Server Pages (ASP) was relatively new at that time. The previous server-side technology I learned to use and implement prior to ASP was Internet Database Connector HTML Extension (IDC/HTX). It was used to access data sources.
* FTP to the web server was not allowed by our network administrator due to security reasons so I had to copy my code on to a disk and walk from my office to another building to copy them on the web server.
* I also could not compile any of my code into dll’s since it was too much work to have to walk to the server room, register it, and to find out that it did not work and having to walk back to my office to go through the process again.
* Having to personally learn a mainframe to web screen-scraping application/language and migrate a mainframe-based registration by telephone/tn3270 application to web interface in 4 months. This meant working from 8 am til 2 am in the morning the next day and in the process getting to know our custodial staff really well.
* Resistance to web sites in 1996 by some technical staff because they did not see the need for one. Almost 15 years later, I am getting the same resistance to the need to incorporate social media and mobile computing into our organization.
* Our department consisted of approximately 4-7 people, far different from the 40+ employees we have now. During that period, I had to personally manage the 1 web server myself although I didn’t have any education on systems administration before then. Today, we probably have more than 100 servers and most of them are on virtual machines.
Codes not only provide the obvious information on the application itself, but they also provide a glimpse of that time period in an organization and thus should also be appreciated.
What other information can codes reveal?