The People Factor in Software


Earlier this week, I was at the Rational User Conference. I was part of a dynamic panel, “The People Factor: Experts Weigh In On The Soft Side of Software.” One question was about how technical managers or project managers have to be. Murray Cantor, one of the other panelists, summed it up this way: “They have to understand the dynamics of software development.” Ellen Gottesdiener reminded us about the value of interim retrospectives. Kurt Bittner, author of Use Case Modeling was our moderator.

I was my normal feisty self 🙂 I wrote up my position statement, and after editing it several times (and changing it the night before the panel), I've decided it's worth posting, at least for comments. If you were at the conference, you'll recognize that I ad-libbed during my opening remarks. Please do comment by email or with the comments here.

The People Factor in Software

The two most important factors for successful software projects are the ability of the managers to manage and the people to understand the domain of the software in which they are working. [1] Capers Jones claims that reuse of high quality components is significantly higher than those two factors, but to be honest, I haven't seen enough reuse to apply that factor to most projects.

What that means is that people matter. And managers matter.

So what do I mean by people matter?

I'm not a people person by nature. I originally decided on a career in software because I thought I'd be able to interact with machines all day and rarely talk to other people. After all, that's how I went through school, and didn't school prepare me for life?

Well, unsurprisingly to us now, I soon realized I spent close to half my time talking with other people: discussing the designs, how we would integrate, who would get computer time, which module would do what thing, and who would manage the work in software that the hardware guys couldn't do. As I became more aware that people are the vehicle by which software is developed, I realized I had to “care” about people.

I don't mean caring about people in a touchy-feely way, although I do recognize that people have feelings. I care about people and they way they interact because that's how we make successful products and projects:

  • It's logical to care about people because if the product is a success but the people all quit at the end of the project, the project was not successful.
  • It's logical to care about people because if they're worried about the rest of their lives, they can't give 100% to the project.
  • It's logical to care about people because if they work so much overtime that they're punchy, they will create defects (if they're developers) or miss defects (if they're testers) or set the organization on the wrong strategy (management)

People are how we make projects successful.

But what about managers? Earlier, I said that managers matter too. Here's why. Good people can triumph over inadequate process or inadequate management. But even the best people with the best process can't triumph over bad management. Bad management trumps everything else. I've worked for bad managers, and I bet you have too, so you've seen the damage bad managers can cause.

Great managers recognize that any software worth doing has to provide significant value over previous (or other) projects. Managers, as well as the technical staff know they have to learn about the software as it evolves so they can manage the unknown risks. As I was driving in yesterday on US 4, I saw lots of construction. I realized that the people rebuilding the road were working on the next release of the highway, something we do in software as a matter of course. But there's huge difference between managing people who construct the next rev of the highway and managing the next software release. With the first release of the road, you've already uncovered most of the construction gotcha's. You know where the water table is, you know where the animal habitats are, you know the ground composition as you move along the highway. In software–any software worth doing–you don't know what you're going to find. Just because you discovered something in the first release, doesn't mean you know enough about how the software has to evolve to understand what's going to happen in the next release, with the new requirements and the changed implementation. You have tons of unknown risks. I claim that the best managers help their staff recognize and manage those unknown risks. The worst managers don't. And because unknown risks can occur anywhere, the best managers use qualitative and quantitative data to understand the state of their projects.

Successful organizations work on the highest value projects; hire people who can succeed in their environment; and teach those people, including the managers about the product. Managers who understand that their job is not just to deliver results for this particular project, but also to continually build capacity and work through and with others are successful. Technical people who are continuously curious about the product and how to make it better drive projects to successful completion.

We need people who are knowledgeable in two significant dimensions: they understand what their job entails (whether they are developers, testers, release engineers, and so on), and they know how to apply that knowledge to the product. We need knowledgeable managers, people who understand how to manage projects and people, and who know enough about the product to make good decisions.

I claim that the practice of software management in 2003 remains significantly behind any of the technical factors in producing great software. When we decide management is valuable and we demand managers perform good management, we will build capacity in each person and our products will improve.

The soft side of software, the people, are the trump card in software projects. Want a successful project? Make sure your people can work together, including their managers, and that they understand the problem and solution domains of the software. Make sure your people have the functional skills to succeed. Then you can select any reasonable process, and the people will succeed.
1. Jones, Capers. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley, Upper Saddle River, NJ. 2000. (page 133).

2 Replies to “The People Factor in Software”

  1. Dear Sir,
    I am a student of Information Systems & Management.I would like to thank you for this post as it has motivated me to base my dissertation on this topic-people factor in software & how this factor influences the success of a software.
    I would be very much obliged if you can assist me in any way.
    Thank you again,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.