Leadership, Teamwork, and Trust: An Interview with James W. Over
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Grady Booch: Over your professional career, you've lived through many generations of software development processes. Are there any observations you can make about the ebb and flow of particular approaches to developing software-intensive systems?
Jim Over: The oldest documented instance of a software process that I am aware of was the nine step process developed by Lincoln Labs for the Semi-Automatic Ground Environment (SAGE) continental air-defense network. The process was used to produce the hardware and software for the SAGE system during the late 1950s. The system was developed in increments. The first prototype was one year late, but subsequent upgrades were at most several weeks late.
The SAGE program production process was a predecessor of Win Royce’s waterfall model from his 1970 paper, Managing the Development of Large Software Systems. Many large system processes and government or industry standards were similar to Win’s waterfall model. In 1985 Barry Boehm published A Spiral Model of Software Development and Enhancement. Barry’s risk reduction spiral model used targeted prototyping to identify and resolve the engineering risks that are so common on large, unprecedented systems. His work influenced the DoD [Department of Defense] standards in the late 1980s and 1990s.
Most of this early work was trying to solve the “crowd control” problems of large systems development. Large software projects require a large workforce. These processes were staged, there was little iteration, and the management style was the “top-down” industrial approach.
But small- to medium-size projects have always used less formal, and even ad-hoc, approaches that worked well if you had the right people. There are many examples of iterative, evolutionary, and team-oriented concepts, but with the Agile Manifesto these smaller project methods and processes are the most popular. Everyone wants to be Agile!
To me the trend is clear. We have evolved from large-grained, staged processes designed for crowd control, towards finer-grained, iterative processes designed for self-managed, small teams of software developers. Personally I think this is the right path for several reasons, but one key reason is management style. Traditional, top-down, management concepts aren’t as effective for software development as the self-managed team style. Peter Drucker, the famous management guru, said that people engaged in this type of work--he called it knowledge work--should be self-managed. We discuss this at length in the book, and Team Software Process (TSP) and Personal Software Process (PSP)1 are based on a self-directed team management style. I know from personal experience that when properly trained and supported, software teams do their best work with this approach.
Grady: And, to follow up, what do you see in the future of processes?
Jim: Many software developers think that a process is synonymous with bureaucracy. This is the crowd control view of a process--something that you’re required to use, that was developed by someone else, and that gets in your way.
A process should be a tool that serves you. It should help you do your work. It should provide a framework for reasoning about your work, planning your work, making commitments, creating solutions, innovating, capturing lessons learned, and improving your performance. These benefits require you to define and own the process, follow it when you work, and gather data on its performance. We developed the TSP and PSP as tools for developers and teams, to help them do their work. They are tools that developers use to satisfy the customer by delivering working software, quickly and efficiently.
The future I would like to see is that teams and individuals view a process as a tool. They own their processes and methods and implement them with good fidelity. They measure them while they use them, and use the data to manage and improve their work. The resulting feedback promotes learning and rapid advancement within the profession.
Grady: If you had you as a mentor when you were just starting in the profession, what do you know now that you would have given advice to yourself back then?
Jim: I had Watts as a mentor for the past 20 years or so, and the best advice I ever received from him is summarized in the last paragraph of the last chapter of his book, A Discipline for Software Engineering. Quoting from this chapter:
“Surprisingly often people achieve their objectives, but in ways they did not expect. Life rarely turns out the way we plan. While our carefully developed strategies may go down in flames, a new and more rewarding opportunity shows up in the ashes. The key is to keep an open mind and to keep looking. In life we all reach the same end, so we need to concentrate on the trip. Just as with a process, once you decide how you want to live, the rest will follow. Devote yourself to excellence, and you just might achieve it. That would be worth the trip.”
Grady: You've had the opportunity to work in many different domains as well, from defense projects to commercial ones and (I imagine) across many countries. Do you see various families of development process cultures, and if so, how would you characterize them? (And what forces do you think caused them to arise?)
Jim: When viewed as a population, different domains and regions often appear to have what you’ve called a “process culture,” but working person-to-person as I often do, these “stereotypes” disappear.
Large, complex systems’ product domains are necessarily more structured. There is external pressure to follow accepted standards of practice, to carefully plan and manage the work. The processes are optimized for the objective, and may seem burdensome to those with little domain experience. The organizations that produce these systems tend to have larger budgets for training, process improvement, tools, etc.
Large companies that have had great financial successful and/or dominate their markets are sometimes frozen. They tend to avoid change or improvement, especially when new ideas originate outside of their walls. They believe that their financial success implies that they are innovative, technically savvy, have great management, and the best workforce and culture.
CMMI has had substantial impact in emerging regions, bringing more structure and discipline.
In my experience people have a greater influence on “process culture” than domain or region. Process, like any other idea or technology, has its innovators, early adopters, early majority and so forth. While innovators and early adopters occupy key positions in management and engineering, progress can be made. When the benefits become clear to early and late majority, the push to establish a process focus shifts to a pull. Eventually the new way of working becomes the old way of working and is widely accepted.
One final observation is that in all settings there is a gap between expected practice and actual practice. Some “process-focused” organizations execute with low fidelity with respect to documented practice. Some process agnostics have very disciplined behavior.
Grady: Suppose Facebook or Google or Twitter would have brought you in for advice when they just began their respective companies. What would you have told them?
Jim: We had this opportunity a few years ago with a startup that was eventually sold to a large company here in the U.S. Our recommendation was to build the product right, from the ground up, using a disciplined process, in this case TSP/PSP, and sound architectural practices based on SEI’s work in software architecture. The project involved a few small teams, scattered around the globe. I’m not sure how much I can share with you without written approval, but I can say that the project finished on time, the quality of the product was quite good, and it was a technical and financial success.
Grady: And, now that they are established, what would you tell them today?
Jim: One common theme with startups is a failure to plan for the growth that follows success. A few highly motivated individuals work very hard to get things started. Eventually they have some success, which leads to more demand and growth. At some point their “entrepreneurial” development methods reach the limits of scalability and the product offering suffers.
Eventually these poor development practices are likely to become a competitive exposure. At a minimum the unnecessary rework introduced by these methods are an unnecessary financial burden, often much greater than 30% of development cost. One organization that I’m aware of has a rework budget that is greater than 60% of development cost.
My recommendation would be to implement a scalable, disciplined process. Introduce new practices on project team by project team basis to control the investment. Use the savings from each project or group to fund the next implementation wave. We have seen organizations save as much as 600 hours per developer per year with this strategy.
Grady: What will the development of software-intensive systems look like in ten years? Twenty? Fifty?
Jim: The widespread adoption of new technologies or methods is measured in decades. Ten years isn’t long enough to produce widespread change in the way developers work. Computing technology, including devices and sensors, tend to follow Moore’s law, which is a much faster pace. In just five years the technology will improve by an order of magnitude, and it is a given that software will somehow grow to use every available byte and clock cycle.
The next ten years will follow the same path as the last ten. Computers will be smaller and faster with more memory. Software development will involve larger abstractions. New tools will emerge to help manage these abstractions, and with luck, developers will spend more time designing and integrating components, and less time writing lines of code.
Organization boundaries will continue to soften as social media leads to more direct interaction among members of various communities.
I think that the profession must take steps to dramatically improve the quality of software during the next ten years or so. Software is now part of the foundation of our society, but software quality seems to get worse. My smart phone crashes frequently and it often exhibits behaviors that suggest that it has timing or state issues. There’s no reason for this. It increases development costs, slows time to market, and would be a serious liability in any other discipline.
What happens in fifty or more years? A fifty year period is a science fiction timescale. Goddard and von Braun dreamed of space travel in their youth. Not much more than fifty years later man walked on the moon. If science fiction can be used as a guide, then fifty years from now software will probably be developed by computers, not people.
Grady: Tell me a personal story or two of some of the software luminaries you've had the opportunity to work with.
Jim: Watts Humphrey and I first met in January 1987 during my interview for a position as a Member of the Technical Staff. Watts was not well known outside of IBM at the time. He had just retired from IBM where among other responsibilities he had managed software, quality assurance, and process. He had joined SEI at the age of 60, and he was starting on a new career when many of us are thinking about retirement.
From the beginning it was very obvious that Watts had an agenda; that he had a mission. What drove Watts? What we didn’t know, and what many people still don’t know about Watts is that he had made an outrageous commitment. He had made a commitment for his “second career” to change the world of software engineering, and he joined the SEI so that he might be able to achieve this goal.
Many years after I joined the SEI ,Watts and I were having dinner and he told me about this commitment and what it meant. He referred me to a Speakout column, in IEEE Spectrum, from April 1986. In 1986 the leaders in the software community were debating the wisdom of the Strategic Defense Initiative, or SDI. Most experts were convinced that it was impossible to build the estimated 10 MLOC of software required for SDI. They reasoned that it would be impossible to produce software of sufficient quality. They believed that defects in delivered software are inevitable, and that building in error tolerance and extensive testing would still not produce software of sufficient quality.
In this article, authored just before he left IBM, Watts defines an alternative to the methods of the day that he felt would work. He talked of building world class software organizations and teams from the ground up, developing the ability to plan and manage software, creating processes and measures to support the software work, and emphasizing quality throughout development. These were the concepts that become the foundation for the work he led at the SEI. It was this vision that led him to make the outrageous commitment and he worked tirelessly at it until last year. It was his life’s work.
Grady: If you hadn't taken your journey into software and processes, what might you have done otherwise?
Jim: I have been interested in computers from a very early age, and later software. My journey into software process and metrics started when I joined the SEI. During the development of the PSP and TSP I became interested in team practices, team management concepts, and technology transition.
While I do have other interests, I have had the good fortune to work with some truly great people, on challenging problems in software, process, and related areas for nearly 40 years. It’s been so much fun that today I can’t imagine doing anything else.
Grady: If you could have dinner with one famous (or infamous, or even completely neglected) luminary from computing, who would it be? (and why, and what would you talk about?)
Jim: I have to tell you that I’m somewhat unpredictable when it comes to topics like this. If you ask me tomorrow I will have a different answer. But recently I’ve been interested in the early history of computing, especially the development of the digital computer. I’d love to have dinner or a drink with someone like Eckert, Mauchly, or Von Neumann. What would we talk about? I just want to hear the stories of the day. What were they thinking about? Where did the inspiration come from? What were the challenges?
1Team Software Process, TSP, Personal Software Process, and PSP, are registered service marks of Carnegie Mellon University.