David Garlan (CS’83,’87) is a professor in the Institute for Software Research and the Computer Science Department, and director of SCS’s Professional Software Engineering Programs. A graduate of Amherst and Oxford, he is a fellow of the IEEE and a senior member of the ACM, and is considered one of the founders of the field of software architecture. In 2005, Garlan received a Stevens Award Citation for “fundamental contributions to the development and understanding of software architecture as a discipline in software engineering,” and in 2011 he received the Outstanding Research Award from ACM SIGSOFT for “significant and lasting software engineering research contributions through the development and promotion of software architecture.” Garlan spoke to Link Editor Jason Togyer.
Why is your office decorated with items related to Frank Lloyd Wright?
I’ve always been inspired by Wright. There’s integrity to his designs, because they’re held together by consistent elements and themesAnd they worry a lot about context. It’s not just the buildings themselves that he was concerned with, but how they fit into their surroundings. When Robert Allen and I created a language for specifying architecture, I decided to call it “Wright.”
How do Wright’s design principles apply to software architecture?
There are interesting parallels. I’m interested in systems whose design naturally matches the domain they attempt to serve—ones that fit neatly into their contexts without creating abrupt changes in experience for their developers or users. The world of software has become increasingly comples—we need to make sure that developers aren’t just creating nice standalone applications, but ones that also fit well into their environments. The iPhone is an interesting example: Apple created the ecosystem and maintained its consistency, so users have a seamless experience as they go from application to application.
What are the ingredients for good software architecture?
Good systems have clean, consistent structures that make them easy to understand, analyze and maintain over time. Sometimes what happens is that the software architect comes up with a good design and the programmers mess it up because they don’t understand the architectural principles; or simply because it’s easier for them to do it some other way.
What were your early computing experiences?
My father was a professor of philosophy at Reed College in Portland, Ore., and my stepmother was in charge of the computing lab there. They let me sneak in and play with the IBM equipment. Unfortunately, at that time, computers were not really mainstream at most colleges. When I got to Amherst, I did some programming for the physics department, but when I got to Oxford, I wasn’t exposed to any. Instead, I studied mathematics, later deciding that I didn’t want to become a mathematician.
What did you do instead?
Many things: I worked in a bakery, I worked in a brewery, I played in a band, and I taught high school and community college. While I was at the community college, one of the other instructors got sick, and I was asked to come in and teach a Fortran class.
You must have enjoyed that.
I did! So much so, someone suggested I apply to grad school at Carnegie Mellon for computer science. I have no idea why I was accepted. Perhaps I was one of those high-risk, high-potential people they were open to accepting in the early days of the department? I was lucky to have Nico Habermann as my advisor.
What was he like?
Nico was inspirational in terms of his vision, his dedication to his students, and his ability to nurture creative thought. It was a wonderful time, too, to be at CMU—a time when many people were thinking about how to support software development with good tools.
What was in the “toolbox” then?
A text editor, a compiler and a debugger, and that’s about it. Nico said, no, no, no, it should be much more. He felt that, along with the tools you needed, we should provide a rich environment to support the development of software, as well as the management of different groups of people who were working together on that software.
You didn’t stay at CMU, though.
No, when I finished my Ph.D., I went to Tektronix in Portland, where I discovered software architecture and the concept of reusing pieces of software as a way to reduce the complexity of systems. But you can’t reuse pieces of software without having a conceptual framework in which to place them. So I came back to CMU to pursue, along with my colleague Mary Shaw, this idea of architecture and help bring it into the mainstream.
Is the idea of software architecture more widely accepted now than it was then?
Yes, but for many people today, the architecture is constrained by the domain in which they’re working—a system for a bank, for instance—and there’s still a long way to go in the industry, because there’s a lot of the attitude, “I build it today the way I built it yesterday.” Moreover, people struggle with maintainability because they don’t think about the long-term evolvability of systems.
Has the need for software to work across multiple platforms improved architecture?
The agile movement has actually somewhat exacerbated the problem, because programmers are often focused on adding features without thinking about sustainability. If people want certain properties built into the bones of a system, then it has to come through a framework and a platform – an architecture – that can evolve over time.
How do you predict what your later needs will be?
The design-time side of software was the traditional focus of software engineering. Over the past few years, there’s been a shift in thought because systems are deployed in ways that we didn’t expect. They need to work when things around them are breaking. We’re now shifting our focus from design-time to run-time.
How does that change software architecture?
New systems need to support much, much more capability for monitoring themselves and fixing problems without being taken off-line. Take security—you can build into the system defenses against all of the known security risks, but what you really want is the capability to deal with unknown attacks as they will necessarily arise. Engineers need to be asking themselves, do I have an adequate number of probes, looking for faults? Do I have enough run-time repair strategies? If I execute certain repairs, will it lead to loss of data or other bad results?
How are universities preparing software engineers for this new world?
Educating practitioners is one of the best ways to spread these new ideas. One of the things that makes our software engineering programs unique is that many of our tenure-track faculty are involved not just in research but in creating our courses for professional masters students that expose students to cutting edge ideas.
How much reverse flow is there, from students to faculty?
A lot, actually. I once received a letter from a graduate who said, “your course in architecture taught me a lot, but it’s not helping me in my current job, because I’m working with existing systems that have lousy architecture, and your course didn’t teach me how to handle that.” That led to a whole new research area for me called architecture evolution.
What activities do you enjoy in your free time?
I enjoy Argentine tango dancing. I also do a lot of gardening. I like to create landscaped spaces—I think of this as the antithesis of what I do at work. When gardening the boundaries are very soft and the time frame is very long—you plant a tree without knowing fully what it will look like in 50 years. It’s very non-algorithmic. There’s also a constant adaptation process of evolving the garden itself to make it what you want to be you and your garden are having a dialog over the course of many years.
# # #
Jason Togyer | 412-268-8721 | email@example.com