June 2001
Volume 3 • Number 3

Contents

TALKING POINTS
Software Engineering: Future or Oxymoron?

by James Cusick, Software Technology Center, Bell Laboratories, Lucent Technologies

The form, content, usefulness, and legitimacy of software engineering as a discipline continues to be debated. This article first discusses the possibility that the term "software engineering" is an oxymoron and then discusses if, instead, software engineering is the future for the design and construction of software.

Key words: software development management, software development technology, software engineering, software engineering education, software process

INTRODUCTION

Recently I was invited to deliver a talk to a group of managers and software developers. I was asked to address the topic of whether software engineering is the future or if it is an oxymoron. I immediately resonated with the proposed title. It seemed like the talk could be fun and could go in many directions while attempting to answer this question. This article reflects the essence of that talk.

SOME DEFINITIONS

Consider the following question: "Is software engineering the future or an oxymoron?" Could it be both or neither? I will begin by defining terms. With definitions in hand, it will be best to first take the case of software engineering as an oxymoron as far as it will go. Following that I will consider if it is instead the future and then attempt to reach a few conclusions. Throughout this exploration special consideration will be given to how software quality plays a special role in software engineering.

One can informally define software engineering as a field related to the creation of software (I will add to this definition later in the article). But what about the terms future and oxymoron? Merriam-Webster's 9th New Collegiate Dictionary defines future as: a) time that is to come; or b) an expectation of advancement or progressive development. Oxymoron comes from the Greek oxys meaning sharp and moros meaning foolish. Thus, an oxymoron is a combination of contradictory or incongruous words or a sharp contradiction of terms, something sharply foolish.

A FOOLISH CONTRADICTION

Is software engineering really just an oxymoron? If so, then what creates this sharp contradiction? What is it that is foolishly out of synch? If it is an oxymoron and not the future, then what should software engineers do? Software engineers know the challenges involved in building software and without software engineering principles, how will they address these challenges? Consider these two questions assuming that software engineering is an oxymoron:

1. What is the essence of the foolish contradiction?
2. What is the alternative for building software-based systems?

Having taught software engineering for many years and at the same time worked as a software engineer, it is difficult to hear people laugh at the term. In thinking seriously about why this reaction is common, one can see the effects of the successes of software development in highly unstructured environments. These loose environments often succeed because of the heroic efforts of one or more individuals. There is a story about something called the "Bill test" at Microsoft told to me by one of Microsoft’s senior architects. Ideas are pitched to Bill Gates who typically responds that he "can do that in BASIC in a weekend." If he finds it beyond that degree of difficulty it is seen as something really special. This type of story, true or not, helps foster the culture of heroism in software development and variants of this story center on other super hackers who are the role models for most. As such, the weekend flurry of genius leaves no room for software engineering, just programming. The view that most successful people in the industry do not approach things from a disciplined manner and do not see software engineering as the way to do things, represents a primary source of the oxymoron view.

A second source of derision for software engineering stems from the truism that many crimes have been committed in the name of a just cause. Some students have reported that in their experience software engineering is just a bunch of people "sitting around creating diagrams that never get implemented." The fact is that good ideas can be applied poorly. Hence, disastrous projects are often blamed on "object-oriented methods" or other techniques. Actually, of the 30 percent or more of software projects that reportedly fail, most do so because of budgeting, planning or communications issues, or product cancellations (Jones 1996). These factors can, in fact, be managed better by applying software engineering. Avoiding such methods will make a project just as likely, if not more likely, to fail.

Software engineering is a youthful discipline—just over 30 years old. If there are rough spots or if it is uneven in performance, it is to be expected. Mechanical engineering, for instance, has had eons to mature. In Egypt, people built sophisticated irrigation systems in the Nile River delta 8,000 years ago. There is a long legacy of success, technique, and artistry that goes into modern buildings and machines that is rooted in ancient experimentation and heuristics. Software does not have this kind of history; it has a wide spectrum of approaches from amateurs to professionals, from spreadsheet tweaks to avionics control software. The field should be given some time to mature. A new generation of developers, instead of smirking at the past, can bring software engineering into its own as a mature and respected discipline within the arts and sciences.

Software engineering is also painted unfairly by the brush of projects that fail to heed its recommendations and then fail to meet business goals. Oxford Healthcare provided an excellent example of this a few years ago (Wall Street Journal 1997). The company was growing fast and was favored on Wall Street. Overnight it recorded losses of $200 million, and in one day lost 50 percent of its market capitalization. The root cause turned out to be a failed IT project. The company was ignorant of how to move from small-scale development projects to the development of large-scale systems. The billing system it built comprised a core business system whose main purpose was to issue bills and collect money. The system stopped working and no longer produced any bills. This created a downward spiral for the HMO. It had designed the system for 750,000 subscribers, but then acquired companies and reached a point where it needed to handle 3 million subscribers. Such shortsightedness could be averted if appropriate architecture and capacity planning were applied. Software engineering as a term does not seem foolish in this instance. The foolishness was in not using software engineering.

SOFTWARE ENGINEERING DEFINED

I have addressed some of the reasons why software engineering as a term is derided, but have yet to define software engineering formally. A working definition will help determine if the oxymoron argument is supportable.

Consider the two terms separately. Software can be defined as the instructions needed to run a computer. Engineering is the art and science of problem solving. Thinking about these terms separately leads to the conclusion that if people fail to use art and science to instruct their computer then they are certainly not software engineers. If, on the other hand, people are using methods, techniques, and creativity to their best effect to develop applications, programs, and systems, then perhaps they are engineering software and may even be software engineers.

There are more formal ways of defining software engineering. The term was coined at a NATO conference in 1968, and a widely accepted definition was soon provided by Bauer (1977). Figure 1 lists the definition and annotates the key points within the definition for discussion.

Software engineering includes the creation of techniques as well as their practice. Today’s researchers and developers may be the source of new additions to the field. Practitioners have often guided the theorists and developed the practical methods common today. Software engineering practice calls on professionals in the field to know the techniques and how to use them. The engineering component of the definition is focused on problem solving. Most developers who would scoff at the term software engineering have strong innate analytical abilities. Software engineering differs in that it seeks to codify these techniques and provide reference approaches to such problems as performance, reliability, and the like. The definition of these practical techniques and workable theories then cycles back into the further expansion of the defined field.
The management side of the definition is also critical to success in software engineering. Management methods allow for the economic solutions to problems. Cost is always a factor in building systems. Software engineering includes management techniques for reducing development costs and operations costs through better processes and better automation of systems, better engineering estimates, and better controls over development. Reliability is a final critical piece. It is not sufficient to create code and wish the user good luck with it—the software must meet agreed-to quality criteria. For quality engineers, software engineering as defined here amounts to an entire parallel field with which to coordinate its approaches, tools, and practices. The quality engineer can at the same time provide and review requirements, develop and deploy best practices, and support quality measurement and attainment of software engineering activities.

Bauer’s definition sets the stage for a formal understanding of software engineering. While I subscribe to this definition, I also see software engineering as resting upon a set of related points. Software engineering, at its most fundamental level, must ensure the predictable production of software. This means that what is attempted is then carried out within predefined measures of success. Within this broad umbrella there are characteristics of software engineering that have specific importance. The software must, in my view:

• Fulfill customer requirements
• Be of known reliability
• Provide an acceptable user experience (fun, useful)
• Be delivered on time and on budget
• Derive its design from requirements methodically
• Support code and documents that are maintainable

Consider these points one at a time. First, the software must meet the customer’s requirements, otherwise it will be just bits on a disk. The art of requirements capture is one of the most important areas in the field. But meeting requirements is not enough. The software must also be of known reliability. This is typically a challenge for most developers who often cannot say with confidence when the software will fail. Experience has shown that it is not a matter of if it will fail but when (Littlewood and Strigini 1992). Responsible engineers should understand an application’s failure profile in advance just as a bridge designer knows the load a span can support. Quality engineers play a vital role in helping software engineers plan the processes that are manageable and achieving designs that attain specified quality levels including but not limited to reliability.

Software should also be fun. The customer should enjoy the software and have a good experience. Software can provide such an experience, and this is typically why programmers got into this work originally, to create cool software.

Further, as with any engineering project, budgets must be managed well. In some cases, budgets are determined under a fixed-priced bid. In other cases, especially on internal projects, it is possible to get additional funding, but one must be close. When remodeling a home, for example, it is common for there to be some unexpected costs, and computer systems follow the same pattern. Software customers need these systems to run their businesses as much as a construction projectÕs customer needs the finished product. Customers may be willing to put up with some slosh, but it has to be within an agreed-upon range.

With the project under way, requirements must be derived in a repeatable and methodical way. Occasionally, all of the features cannot be built at once, so a common approach is to prioritize features and implement the top candidates. A successful approach is to first lay out the end-to-end architecture, and then go deep in key functional areas then iterating back for more. This cannot work if architecture has not been done or if the right componentry has not been established and the team fails to remember where the hooks are to build upon. Executing comprehensive tests between such iterative builds is an often-overlooked but key requirement to success in such an approach. Software engineering, or any other approach to building software, has a set of challenges that at a minimum includes this list.

OXYS YES, MORONS NO

So where does all this lead? This article has addressed where some of the mindset comes from that would view software engineering as an oxymoron and how software engineering is formally defined. Clearly, this is an important field—software drives much of the economy, and for many companies it provides a critical value-added layer to services and operations. There seems to be no inherent foolishness in putting software and engineering together as a term. It does not seem foolish to apply proven tools and tested methods to problem solving. Applying scientific (also known as proven) knowledge to software development should be anything but foolish. Thus, one can conclude that it is not an oxymoron.

WHAT ABOUT THE FUTURE?

If software engineering is not an oxymoron, is it instead the future? While most people attempt predictions of the future despite its difficulty, I will not be so bold. Instead I will try to state where the field is today, what direction it is heading, and then surmise what role software engineering might play in the future of software development.

Dead Reckoning

I consider myself an engineer (at least I did until I became a manager). When people ask me what I do for a living I say that I artfully contrive solutions to problems. That is how Merriam-Webster’s 9th New Collegiate Dictionary defines an engineer:

"A person who carries through an enterprise or brings about a result especially by skillful or artful contrivance."

More than half of all Association for Computing Machinery (ACM) members call themselves software engineers (Buckley 1993). It is safe to assume that they do not see the term as an oxymoron. Nevertheless, a definition for the field is still in debate as is the taxonomy of the field (Tomayko 2000). There are no entry criteria to the field, and there is no way to determine competency. Debate continues around what is ethical. Many software projects, however, create life-critical systems, such as medical devices, flight control systems, and military programs. In speaking with a medical devices company, I found they have a different concept of defects since bug repairs would require surgery. Many people involved in the software business do not see their applications as life critical when in fact these systems can have severe consequences if they fail. To date there remains limited oversight of the field, and software is delivered with as-is warranties. People develop software willy-nilly, and society depends upon these systems in a myriad of instances.

While many software engineering standards exist, including those covering lifecycles, requirements specification, unit testing, quality assurance, and configuration management (Moore 1998), a healthy debate continues over how the field is actually composed. Recently some progress has been made in defining the content of the field through an ambitious if contentious project called the body of knowledge (BOK) for software engineering, which is supported by numerous industry groups (Abran and Moore 2000). The current version of the Software Engineering BOK (SWEBOK) is embodied in a "stone man" draft that details the subfields of software configuration management, software maintenance, software quality, and software test (Bourque 1999). One might compare this evolving BOK with the existing Certified Software Quality Engineer (CSQE) BOK provide by ASQ. The CSQE BOK covers quality, software quality management, processes, project management, metrics, testing audits, and software configuration management. To casual readers there seems to be some overlap between these two descriptions of two intersecting fields. One might wonder if all of these efforts to define the content of the fields related to software engineering could
be coordinated.

THE PRACTICE IS NEEDED

In the face of this ill-formed or at least multiply- defined field, a reasonable question to ask is if a fully formed field would be useful. To answer this question a review of the many recently failed online Internet systems is instructive. When these sites go down people lose money (for many this is only second in importance to life-critical systems). Ameritrade, E-Trade, and Schwab were all racked by outages in 1999. eBay, the online auction house, was hit by a class-action lawsuit for several billion dollars recently. What caused these failures? Software-related issues were the main causes: software failures, poor software upgrades, configuration errors, and performance problems (Kerstetter 1999). These are basic blocking and tackling issues from the software engineering point of view. Of course, there are some serious operational issues due to the scale and volume these sites are required to handle—software engineering might not be able to help with such computer operations issues. Even in these cutting-edge environments, however, the same fundamental problems that software engineering solved long ago keep cropping up. The software engineering practice is needed without question.

SOFTWARE ENGINEERING CAN PAY OFF BIG

Of the many areas that software engineering covers, there are certain things that have a high payoff and should meet the needs of the practitioner and provide motivation for applying software engineering. If the basics have been covered, including configuration management, requirements, project management, and testing, what else should be done? The biggest payoffs include peer reviews or inspections and measurements that provide a view into one’s business that is objective, modifiable, and actionable (Jones 1997). If one has the right measures in place in his or her lifecycle, of which some may be technological, performance, or management related, areas for improvement and progress achieved will become visible. Other big payoffs have been documented by application of the Software Engineering Institute’s Capability Maturity Model (CMM®), prototyping, and reuse, especially at higher abstraction levels.

The Economy Depends on Us

Beyond the practical need for software engineering and the benefits it can bring, the economy really does depend on software and information technology. Alan Greenspan, chairman of the Federal Reserve, and a very conservative thinker, sees IT as the basis for the last eight years of economic expansion. He recently testified to Congress that:

"… [our] run of economic growth that appears to have its roots in ongoing advances in technology…innovations in information technology…have begun to alter the manner in which we do business and create value (Greenspan 1999)."

This view makes it even more important that software professionals execute well. The field must deliver what it promises.

WHERE IS SOFTWARE ENGINEERING HEADING?

Software engineering today can be summed up as being pervasively referenced by software practitioners, needed by the industry, beneficial when applied, and supporting broad economic dependencies. Despite an economy that depends upon software engineers, they still have no agreement on what the field contains. So where might software engineering be going?

Students to Lead

In my role as an educator, I think about the future in terms of my students: who they are, what they are learning, and where they are going because that is the future, and they will be bringing us there. Today if one signs up for a graduate degree in software engineering he or she will be required to follow a program much like that in Figure 2 (Ford 1991). The knowledge and skills driven by this curriculum will be the reference kit of next year’s new hire. Some of today’s practicing engineers may have had these courses, but many veteran development staff members and managers may not have been schooled in this manner. Some of today’s students are very impressive. They know several modeling approaches, the latest languages, enterprise architectures, and so on. Some do not have the end-to-end context required to lead and manage projects but will quickly attain that experience. Unfortunately, many students later report that the company they work for just does not get it. That is, their ideas from school are more advanced than their employers can adopt. They will be pushing on new ideas, however, and pushing us further.

Best Getting Better

While students are gearing up to lead, the industry is also getting better. The best companies are getting better. Looking at the changes reported in the CMM levels over the last few years (see Figure 3) there is a nearly 20 percent decrease in the number of level 1 projects and a proportional increase in the number of level 2 and above projects (SEI 2000). This is a type of red shift phenomenon. One can tell where software engineering is headed from where it has been. While one may criticize the CMM as bureaucratic and focused on documented processes as opposed to documented product success, companies have reported much higher performance levels in terms of lower costs and higher quality when achieving higher process maturity (Bagert 1999).

CERTIFICATION OF SOFTWARE ENGINEERS

With the advent of standards for software engineering it has become possible to also certify software engineers. In civil engineering a handbook of standard engineering practices exists, which all practicing civil engineers are tested on. They are then required to maintain in good standing with the appropriate government agencies to ensure knowledge of and compliance with these standard practices. The argument has been made that for those people developing software, an equivalent approach must be taken. Thus, the SWEBOK described earlier is cited as the stand-in for a comprehensive handbook for the field in order to provide a definitive basis for a determination of mastery of the field.

For software quality engineers, the ASQ CSQE designation has been available for several years, as well as many other certifications in the application of reliability, process, and quality (www.asq.org/cert/types/index.html). For software engineers such a designation has only recently become available from a U. S. government agency, namely, the state of Texas (www.tbpe.state.tx.us/). Texas offers certification via a waiver given specific degree and experience or by an examination that is based on work by the ACM and IEEE Computer Society (Romanak 1999). At press time, more than 50 such certifications had been issued.

Most recently, the IEEE Computer Society announced it plans to offer a certification exam later this year. This program will offer a Certified Software Engineering Professional (CSEP) designation based on demonstrated knowledge in software configuration management, construction, design, testing, maintenance, quality, software engineering tools, methods, processes, and management, software requirements engineering, and engineering economics (Piner 2001). The potential effectiveness of such certification programs has been hotly debated in the industry. It seems clear that such efforts result from the increasing importance of this field to the public and to the maturation of the methods of software engineering in that concrete codifications of the field are being evolved to the point of standardized tests.

SOFTWARE ENGINEERING AS THE FUTURE?

If software engineering’s direction includes more focus on methods, process, and planning, will it remain in the future as something useful and needed? Also, what must software engineering provide in the future to remain useful and needed?

According to van Vliet (1996), software engineering must handle the following tasks:

• Support the development of large-scale systems
• Help master complexity
• Facilitate organization and communication
• Manage the evolution of software
• Help engineers and teams to achieve results efficiently
• Help engineers and teams to achieve effective solutions

Building one-off software applications or applications of limited scope may not require much in the way of software engineering. Handling large-scale systems development will continue to require coordinated architectures, sophisticated business model analysis, and will need to be built for evolution. This is supported today by software architecture, architecture styles, and distributed object approaches. Complexity can be managed with modeling via unified modeling language (UML) and with component technologies. Project management and certain process models can help with organization and communications challenges. The evolution of software requires better up-front design but also better reengineering tools. This is especially true for Web environments that are typically built as throwaway efforts but will soon be too expensive to be treated in this manner. Getting to solutions efficiently will require the application of measurements and estimation. Finally, getting to effective solutions will require capturing needs correctly (requirements engineering) and a focus on usability and testing methods. In all of these areas, technical approaches exist. In some of these areas, however, significant gaps remain, and software engineering must grow to meet these and future needs.

WHAT OPTIONS DO SOFTWARE ENGINEERS HAVE?

If software engineering cannot meet future needs, then what else can be done? There are many ways to develop software. A subset of these approaches might include:

• Hobbyists
• Hacker (as artisan) or hacker (as unskilled or pirate)
• Informal teams
• Process-oriented teams
• Open source
• Experimental/educational/research
• Technology (natural language, code
generation)

Consider these approaches one at a time. It should be noted that many significant software products were developed by hobbyists or amateurs. A good example is the first spreadsheet developed by two business school graduate students. This source of software will continue to be a hothouse both for products and for talent because of the ubiquity and low entry cost of computers since the advent of the PC. This approach, however, does not scale well and cannot solve the future requirements outlined previously.

A "hacker," according to Eric Raymond (1999), is an artisan, problem solver, and enthusiast. This term also stems from the much earlier times (circa 1620) and refers to an inexperienced and unskilled person. Within the software community hackers might be very skilled programmers or programmers attempting to use computers for criminal activities. It is also common to hear reference to "hacking up some code," which might mean programming skillfully or throwing something together inelegantly. As a whole, this approach relies on some degree of heroism and individual effort of some distinction. As an alternate to software engineering none of these interpretations leaves much confidence that this model is anything more than a professional version of the hobbyist. This approach also falls short of our needs.

Informal teams and process teams can both play a role in solving the needs outlined previously. For smaller efforts and less-critical operational environments, a loosely structured team might work well. Developing elaborate process-driven teams has also proven to fulfill the needs at hand. By defining the phases of work, inputs, outputs, roles, and responsibilities, and then managing this process carefully, it has been possible to build many of today's largest and most successful systems.

Of significant interest recently have been open-source projects such as Linux, Apache, and others. The approach centers on loosely coordinated teams working on problems of interest and relying on extensive peer review. While this approach has produced laudable results, there are weaknesses in projecting that it will meet future technical and managerial needs. The open-source community is largely a "by programmers, for programmers" culture. Today’s open-source solutions include compilers, editors, browsers, and assorted system-level software. Doing interesting projects is the goal. This is often the opposite of society’s needs. It is generally not very interesting to the independent code artisan to solve yet another financial analysis or retail application problem. Further, open source requires as a prerequisite the ability and availability of volunteer hacking. By most accounts funding must be derived from activities in addition to the hacking of open-source code. By definition this precludes open source as a broad solution for software solutions development that must be predictable in budget, scope, and schedule. Linux was developed over a 10-year period by thousands of individuals. An important question for software engineering is whether this could be repeated and if so, how long would it take. Open source has played a role in software from at least the early days of UNIX, if not earlier. It will continue to play a role in the future, but it is not likely to be the future for all software problems.

Aside from various academic environments and experimental approaches to software development, the only other significant alternate will stem from technology. Natural language interfaces may, in the future, allow engineers to create software in radically different ways. Biocomputers may be genetically engineered to replicate in self-adaptive ways to the information processing and storage needs of future application demands. The promise of achieving a world like the one described by Kurt Vonnegut in Player Piano (1952) where machines would build still more machines seemed fanciful 49 years ago. Today, all one needs to do is walk into an automobile factory to see this vision as reality. The software world of the future may mimic this reality sooner rather than later. Until then, process and engineering methods will continue to evolve to bring us to our near-term future of more efficient and effective systems realization.

CONCLUSIONS

In summary, if there is no foolish contradiction and since one cannot foretell the future and as there seems to be no legitimate alternative, perhaps the debate should be tabled and the focus should be on adopting current best practices and advancing research in the field. Of course the hacker/artisan model will be used and will achieve good results in some niche cases, but for big problems, software engineering will be the preferred and, in many cases, the only acceptable approach. Naturally, this does not mean that one should try to employ the entire software engineering body of knowledge on every programming task. Instead, intelligence must be used in selectively employing the techniques that solve immediate problems in software development.

Software engineering is, in the final analysis, neither future nor oxymoron—instead it is an option today. If software engineers want to sit in their basement and crank out the next great Web applications, they would be foolish to use software engineering dogmatically—but they are wise to engineer their software. If they have agreed to help build next-generation systems of scale and criticality, however, they will need to find the right blend of art and science to succeed and must choose wisely from the methods offered by software engineering.

ACKNOWLEDGMENTS

Topher White and Margaret Dorchester of AT&T Wireless provided both the inspiration for the talk on which this article is based and the forum for the talk. Professor William Tepfenhart of Monmouth University and Irwin Schpok of Bell Labs provided extensive comments on early drafts, which significantly improved the readability and clarity of this article.

REFERENCES

Abran, A., and J. Moore, eds. 2000. Guide to the software engineering body of knowledge: A stone man version. Los Alamitos, Calif.: IEEE Computer Society. See URL www.swebok.org.

Bagert, D. 1999. The licensing of software engineers and its effects on certification. First International Software Assurance Certification Conference, Chantilly, Va.

Bauer, F. L. 1972. Advanced Course on Software Engineering. Technische Universitat Munchen, Bayerische Akademie der Wissenschaften.

Bourque, P. et al. 1999. The guide to the software engineering body of knowledge. IEEE Software 16, no. 6: 35-44.

Buckley, F. 1993. Defining software engineering as a profession. ACM Computer (August): 76-78.

Ford, Gary, ed. 1991. SEI report on graduate software engineering education (CMU/SEI-91-TR-2). Pittsburgh: Software Engineering Institute, Carnegie Mellon University.

Greenspan, A. 1999. Congressional testimony. Washington, D. C., 14 June.

Jones, C. 1997. Applied software measurement: Assuring productivity and quality, second edition. New York: McGraw Hill.

———. 1996. Software systems failure and success. Boston: International Thomson Press.

Kerstetter, J. 1999. Warning! E-Com under construction. PC Week 16,
no. 25: 1, 22.

Littlewood, B., and L. Strigini. 1992. The risks of software. Scientific American (November): 62-75.

Moore, J. 1998. Software engineering standards: A user’s road map. Los Alamitos, Calif.: IEEE Computer Society Press.

Piner, M., ed. 2001. Society to offer software engineering professional certification. Computer 34, no. 3. (March): 82-83.

Raymond, E. 1999. The cathedral & the bazaar. Sebastopol, Calif.: O’Rielly.

Romanak, J. 1999. Software quality assurance independent testing: Life as a CMM level 5 test organization. In Proceedings of the 12th International Software Quality Week, San Jose, Calif., May.

SEI Software Engineering Measurement and Analysis Team. 2000. Process maturity profile of the software community 1999 year-end update. Pittsburgh: Software Engineering Institute, Carnegie Mellon University.

Tomayko, J. 2000. A historian’s view of software engineering. In Proceedings of 13th Conference on Software Engineering Education & Training, Austin, TX. Los Alamitos, Calif.: IEEE Computer Society.

van Vliet, H. 1996. Software engineering: Principles and practice. New York: John Wiley & Sons.

Vonnegut, K. 1952. Player piano. New York: Charles Scribner & Sons.

Wall Street Journal. 1997. Oxford Healthcare’s IT crisis. Wall Street Journal, 11 Dec.

BIOGRAPHY

James Cusick is the director of the Software Component Technologies and Services Department of the Software Technology Center of Lucent Technologies’ Bell Laboratories Division. He manages a diverse team of software technologists, developers, designers, and usability engineers who consult with Lucent software teams to develop software solutions. Prior to joining Lucent Technologies, Cusick developed software and managed a variety of projects for AT&T and AT&T Labs, including work on object technology, development tools, process engineering, and metrics. Prior to joining AT&T Cusick held technical roles with a startup-firm, Advanced Data Systems, which provides medical and management software and services.

Cusick also taught software engineering from 1993 to 1998 at Columbia University in New York, where he held positions as an adjunct assistant professor at the Department of Computer Science and as an instructor in the Computer Technology and Applications Program. Cusick is a graduate of both the University of California at Santa Barbara and Columbia University. He can be reached at Software Technology Center, Bell Laboratories, Lucent Technologies, 600 Mountain Ave., Murray Hill, N. J. 07974, or by e-mail at jcusick@lucent.com.

If you liked this article, subscribe now.