|
|
Source Code
Analysis
This was my first large professional project. The Used Computer Store of Berkeley
needed a Point of Sale system for registering and tracking sales and repair contracts.
The store at the time was using carbon paper sales receipts; several employees
had complained about the time it took to handle sales returns, and there were problems
with lost reciepts for both sales and repairs. I spoke with one of the owners, who
had decided that it would be too expensive to purchase a system to meet there needs.
Since I had been working for the store, he felt that I would be able to create
a program that matched the store's needs closely at a lower cost.
There were several problems that came up quickly. First, the owner wanted to use inexpensive hardware, and chose to use several old 80386 boxes running under MS-DOS. While this simplified some aspects, it appeared difficult to manage a real-time network in that environment. Second, he wanted the system designed in a way that he, a former FORTRAN programmer, could maintain the program after I had finished it. Thus, it was decided to use FoxPro, which (he believed) would present no problems; he had concluded that the 'visual tools' would make the project trivial. Finally, his wife, who was his partner in business and the real manager of the store, opposed the project; she insisted that I perform phone support for the store while I worked the program, so that the money I was paid wouldn't be 'wasted' (which she felt any time spent on programming would be).
I spent the first two weeks of January 1996 familiarizing myself with the language and environment. I quickly concluded that the visual tools in question would be more of a hinderance than a help, and decided to code the screens directly. I ended the month laying out and coding a core menu which the rest of the program would be built out of, and began writing the key sales handler. This proved more difficult than expected, partly due to my inexperience with the FoxPro language. By late March, however, I was ready to test the sales program prototype, which I wanted to demonstrate before proceeding to the sale-return handler. I estimated that I could complete rest of the planned features by May 1st.
I was never given the opportunity to do so. The manager, already displeased with the project, became incensed at the buggy and incomplete program, despite my insistence that it was only in testing. She refused to allow anyone to use the testbed, making effective analysis of the problems impossible. The real end of the project came, however, when I went to review the existing code with the owner, who found the code incomprehensible (I recall the turning point being when I had to explain to him what a while loop was). The project was cancelled in early April (to this day, the store still uses carbon paper for receipts), and I was given rights to the code.
The project shows several weaknesses which stemmed from my inexperience. I took on the project without clearly determining the needs of the client, particularly the manager, who disliked working on computers herself (an irony that would be more frustrating than humorous). I failed to sufficently familiarize myself with the language, and so went through several redesigns as I learned of the pitfalls of the tools I used. I often used rather unprofessional, even immature, naming for variables and modules. The comments contained many irrelevant or flippant remarks as well. My code documentation, while extensive, was poorly laid out; I hadn't taken the time to write more than a few brief lines of user documentation either. I did not have the knowledge to test it thoroughly before releasing the prototype before the first run of tests. Despite all of this, it nonetheless was an important experience, and was fairly successful given the limitations imposed.