I agree that the software engineering industry delivers some stunningly successful projects, devises some highly elegant solutions, and often goes about its work in a very professional manner. But for every successful project, multiple unsuccessful projects falter. For each elegant solution, numerous ugly and convoluted software systems are delivered. And for each professional, there are those who blindly program their way through the day.

Somehow we seem to have settled for an approach to software engineering in which we constantly adapt to and make excuses for obvious shortcomings. Think about the following questions for a few minutes. Should we accept today's programming languages as an adequate basis for performing our work? Should we accept UML or current architecture description languages as a vehicle for creative and explorative design? Should we accept that the prevalent work practices of our discipline have each of us working in our own private workspace in our own private cubicle?

I would pose that honest answers to these questions reveal serious problems with our discipline. Modern programming languages are a form of least common denominator, requiring incredibly large and detailed implementations of our solutions; implementations that further are difficult to reuse. UML and architecture description languages as they exist today are notations for documenting the outcome of a design process, not vehicles for engaging in it. The use of private workspaces leads to isolation, which is in stark contrast to the fundamentally collaborative nature of software development.

Many additional questions can be asked that lead to similarly alarming answers. We face a deep and difficult intellectual challenge with respect to the underlying assumptions, understandings, and even philosophy of our discipline. Meeting this challenge requires a dramatic rethinking of all aspects of software engineering. Clearly, I cannot (and do not want to!) do this alone. My research focuses on a small number of areas only; areas that I believe are key determinants of where software engineering should be and hopefully is headed as a discipline. Specifically, my work attempts to understand and advance the role of design, coordination, and education in software.

Design
Design is one of the least understood aspects in all of software development, but also one of the most interesting and critical. Design represents an intricate blending of art and craft, of creative exploration and pragmatic comparative evaluation, and of engineering decisions and a sense of style. It is exactly this mixture that makes design a fascinating topic of study. At the same time, the mixture contributes to our lack of progress to date: how to address these concerns together in a single approach that helps to advance the practice of software design?

Most work in the area of software design has focused on notations to capture a design and analyses to ensure that a given design exhibits a certain set of desirable properties. This work could be said to focus on design – the document. It is vital work, since we have to be able to express designs in a tangible manner in order to manipulate them. Advertently or inadvertently, however, notations and analyses are mostly used when documenting a design after it has been completed, not earlier.

My work focuses on design – the activity. A particular concern is creativity during the design process. We cannot make people more creative than they already are, but we certainly can put fewer hurdles in front of them. EASEL is an example of a new design environment that we are exploring. It centers on the use of layers to support incremental and exploratory design of software architectures. ArchEvol takes a different slant, working towards extending the kinds of architectural design decisions one can explore with a concern-based approach.

While they both focus on the activity of design, EASEL and ArchEvol nonetheless set forth unique requirements for design notations. xADL 2.0 is an extensible architecture description language that facilities the rapid construction of such notations.

Coordination
Coordination is at the heart of any software development project. Yet, we know comparatively little about how developers actually coordinate their efforts. Manufacturing-like processes play a role, but so do a wide variety of social and cultural conventions, informal practices, personal preferences and style, and even the organizational structures at hand. Coming to an understanding of these factors, their relationships, and how to best support the coordination needs for a given setting is a challenging problem that makes for a fascinating research area in which many interesting and fundamental issues still must be resolved.

My particular research focuses on assisting programmers when they make modifications to the same source code base in parallel. This is the domain of configuration management, where precise processes, in the form of configuration management policies, have ruled practice to date. My work explores a new paradigm, continuous coordination, which blends formal development processes with informal awareness mechanisms. Application of this paradigm results in new approaches and tools that guide developers with broadly-defined processes, but at the same time continuously inform them about relevant activities surrounding their efforts. This allows a flexible practice to emerge, one in which developers can and are encouraged to self-coordinate early on, before problematic situations get out of hand. This reduces both the number and magnitude of coordination problems that otherwise would arise.

The Palantír prototype brings continuous coordination to configuration management by informing developers of the severity and impact of relevant parallel changes in other workspaces, thereby helping them to avoid conflicts when they check in their code. Lighthouse is similar to Palantír in its objective, but uses an alternative route of exploration based on a different level of abstraction, the emerging design. The Workspace Activity Viewer visualizes parallel work on a project wide basis, live and in 3D. This presents a different perspective that provides the opportunity to detect trends and patterns in the development process, particularly through the movie facility for replaying historical data. PADME aims to understand open source software development processes, practices, and communities by analyzing and relating diverse sets of project data.

Education
I have always been fascinated by the topic of software engineering education, particularly because education is a setting where it seems that many concerns from real-world practice are amplified. We somehow must impart an overall impression of software engineering, explain and illustrate strengths and weaknesses of alternative approaches, and instill not just basic knowledge but also an extensive practical skillset.

Traditional research in software engineering education tends to focus on the materials to be taught or the kinds of class projects to be used in training the students. My research complements these efforts with a focus on finding new delivery methods for the materials to be taught. It is there that I believe the greatest advances are to be made, because traditional lectures and class "toy projects" are valuable, but by themselves direcly insufficient to properly train aspiring software engineers.

My first explorations created new methods for teaching the software engineering process, a topic that can be taught in the abstract, but that cannot be sufficiently practiced in class projects because of time and scale constraints. Problems and Programmers is a physical card game in which opponents play managers who must bring a software project to completion before their competitor can. SimSE is a graphical educational simulation environment in which students once again are managers and play different process models (e.g., waterfall, incremental, inspection) in which they must complete particular projects. Both Problems and Programmers and SimSE strongly encourage students to use good software engineering practices, as the chances of winning a game significantly increase when they do so. In addition to continuing these projects, we are now exploring how EASEL could be leveraged in the classroom to radically change how we teach design.

Environment
Framing my research in these areas is the observation that the environment in which we practice software engineering has not fundamentally changed for decades. By environment I do not mean the software tools that we use, but rather the physical set up of the single computer, single monitor, and keyboard and mouse that the typical software developer has on their desk. Unlike other fields, which have embraced and made great breakthroughs through explicit use of advanced hardware, software engineering has made no forays into this direction.

My research develops solutions that are situated in a high-tech software engineering environment. That is, the research prototypes are explicitly designed to take advantage of advances in hardware, be it multiple monitors, interactive whiteboards, a server farm, high-resolution wall-sized displays, or alternative input devices. While certainly not the norm yet, increasing numbers of software engineers have these technologies at their disposal. Lighthouse is an example of one of my projects that relies on the presence of at least two monitors. The next version of ArchEvol likely will do so as well, and an appropriate adaptation of EASEL appears to be a promising approach towards supporting creative design on interactive whiteboards (not just in practice, but also in education!). Finally, the Workspace Activity Viewer is planned to be used on a large-scale, high-resolution wall display. Building upon these projects, I am now expanding my efforts towards establishing a laboratory for studying and practicing high-tech software engineering.