Home > Articles > Programming

Leadership, Teamwork, and Trust: An Interview with James W. Over

Grady Booch talks to James W. Over, the co-author of Leadership, Teamwork, and Trust: Building a Competitive Software Capability, about the evolution and future of the software development process, a common failure of most startups, and learning about Watts Humphrey's outrageous commitment.
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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020