Article

Are We Engineering Software or People?

Dietrich Kappe

Published on: February 23rd, 2009

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

I had a nice little vacation this past week in Los Cabos. It’s always sunny, 80 and it never rains. Very nice. My wife and I had another installment of our long-running discussion called “Computer Science is not a science.” My wife is a real scientist with a Ph.D. in physical chemistry, and so she has a bit of a chip on her shoulder about the whole “science” thing. It’s a one-sided discussion because I agree with her. Computer science is not about experiments and the scientific method, it’s about three or four different and disparate areas — mathematical computer science, AI or clever algorithms, chips and clock logic, and software engineering.

Then she told me that she thought of me more as an engineer. That got me thinking. Am I really an engineer? A person trained and skilled in the design, construction, and use of engines or machines, or in any of various branches of engineering?

Sure, I build software machines, but how much of the success of a software development project is in the design and building of those machines? Don’t get me wrong — we know what we’re doing. We design web and desktop applications all day long. We design and build them well. But in the collective decades of software development experience at my firm, the consensus is that what makes or breaks a project is people and process.

That’s why we use various Agile tools and techniques. We scrum in a large measure because the alternative is teams losing focus and working on non-critical items or sitting in endless status meetings that end up inadvertently increasing scope. We deliver software in short iterations of two weeks or less because the alternative is wandering at random around the requirements landscape and finding yourself with a product at the end of twelve months that nobody wants. We do test driven development and continuous integration because the alternative is a three-week long integration, build and deployment phase. We do sprint review meetings because the alternative is folks griping about what’s wrong with a project and nothing ever gets fixed.

In short, the things that go right or wrong with software development projects are not about technology or software engineering but about creating effective organizations. That’s people engineering. For more on how engineering organizations can go wrong, see Edward Tufte’s seminal article on the Challenger Disaster and the over reliance of NASA on Power Point.

You may have seen projects fail because of technology. I have. But I can count those on the finger of one hand. Mostly, I engineer teams. I’d love to hear in the comments from others on their thoughts and experiences.