Several months ago, I read an article by Grady Booch, "Object Oriented Development." Booch refers to software objects "suffering"; they suffer sampling, suffer requests for information, etc. Later in the same week I read a hardware system specification by Phil Harter of CSI. In this document, the hardware "enjoys" attributes: the receiver "enjoys a front panel test connector" and the system front end "enjoys a tunable notch filter." The wording struck me at the time, and I’ve thought about it since. I now believe they illustrate a fundamental difference between software and hardware disciplines, at least at my place of work: software suffers while hardware enjoys!

I think the reason for this is that software has become, de facto, the glue that holds systems together, or the rubberband that pulls them together when they’re falling apart. In other words, software has taken over the task of interfacing systems, both internally and with external entities; and interfaces are always the most difficult thing about almost any system. As a result, many software engineers are unacknowledged systems engineers, in that they have to be not only experts in the task of implementing the software design correctly, but also in the domain knowledge, so that they can implement the interfaces correctly. This is a position that really can cause suffering.

An additional difficulty for software engineers is that communication about our designs and requirements is done in a much more abstract fashion than it is in hardware. This is because we haven’t progressed to "chip software" – shared expectations of reusable component behavior. (Recent work cataloging design patterns may help here.) An additional problem is that many development efforts are based on a preceding effort, either the actual body of code or the body of knowledge contained in the engineering staff. Since neither of those can be poured into a new system to see how they work in a new environment, there are frequently huge differences among marketing, engineering, management and the customer community in both perceptions of the current product and expectations for the next generation. And (of course) everyone’s perceptions and expectations differ from reality .

Based on this assessment, I think there would be a high pay off to research into methods of promoting the match between people’s various mental models, and reality with respect to both what the software should do, and what it currently does. Just as important, we need tools to promote communication of the shared vision of the software, so that as the development cycle goes on and the number of contributors and consumers gets larger, we can extend our shared vision of the outcome.

This insight is not earthshaking, but I think that my 20 years of experience in the custom system development arena has prepared me to see its consequences particularly clearly. I’ve observed many programs through the first stages of their life cycles, and all the successful ones shared the characteristic that the entire team, including customers, always understood every day where, on that day, the program was headed. In most cases, this was possible because the entire team was knowledgeable in the domain, if not expert, and some senior person in the program had a compulsion to tell everybody everything. Since very few programs can boast either of these characteristics, we need to develop processes to encourage the distribution of knowledge, and tools to make it easier.

Since all change costs money in the short term and all formal process costs money forever (not that the investment isn’t recovered, but . . .), the first step to implementing these tools is to show that they will result in an improved software development cycle, either by lowering cost or increasing reliability. I think that distribution of knowledge is the inverse of uncertainty. Specifically, I would like to model the cost of uncertainty over time, in large program development. It’s generally accepted that the later the change, the more expensive it will be, and I believe that absolutely. In addition, it may be true that the number and timing of changes in a program can be mapped to the amount of uncertainty in the program, as opposed to the amount of identified risk. This could result in different staffing profiles, different emphasis for technical audits and reviews, and potentially shorter program execution schedules or more reliable software as an output.

My experience in industry has trained me to recognize, frame and solve specific technical and business problems. I really look forward to more exposure to new areas, new disciplines, new ideas and new people to expand my technical world view and enlarge my repertoire of solution techniques. I expect that by returning to school I can recognize more of what problems have already been solved, get guidance in identifying and selecting problems for academic research, and possibly help identify specific interesting problems from the commercial world.

I am looking forward to the opportunity to take classes to develop the specific skills and vocabulary to work in an academic environment. And, my years in industry have developed some characteristics that I hope will be useful in a graduate student: a sense of when to be patient and when to "call in the cavalry," a drive to probe customer requirements until I understand them, a high tolerance for ambiguity, and being really, really tenacious. My resume is attached to this document; I hope it describes a career in which I’ve taken on responsibility for systems and for people, and been successful at managing both. When I complete the program, I hope to have developed more insight into the software development process, both for myself and my industry. I’d like to use that for teaching, either in industry or at a university.

I value UCSC’s excellent technical reputation, but I am also very interested in coming to UC Santa Cruz for its evident cultural values. Part of my present job is to interview job candidates. I’ve noticed that there is definitely a similarity between the candidates from each school; and I’ve loved the UCSC characteristic attitude of openness and excitement. I’ve visited the campus and chatted with several staff members, both in person and via e-mail, and I get the same feeling of excitement and non-defensiveness. UCSC seems a place I can prosper in learning.

I am really motivated to understand how to "do software" effectively, and I think I could begin to learn that at UCSC. I also think my industrial experience could bring a valuable perspective to your department. Maybe, eventually, we can change our expectations to "enjoy software!"