Are We Engineering Software or People?

Dietrich Kappe, Monday, February 23, 2009 @ 4:23 pm

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 getting 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 artical 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.

Related posts:

1. The Origins of Software Engineering Economics — You are Ron Turcotte
2. What Software Developers Should Know Coming out of School – Part 1
3. Ten Keys to Successful Software Development: #9: Respect the Process
4. Software Development and the Construction Analogy
5. Software Development and Wasted Motion

Comments (5)

Software Development

Comments: 5 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Hi,

   Its a coincidence you raise this point today!

   I would describe my self as more of a Software Engineer but merely because of my qualification title. I finished a degree in Software Engineering not Computer Science is this possibly the only difference for me?? Yeah probably

   Also with you mentioning people making or breaking you I agree! Over recent weeks we have been having various discussion on management of clients – as a team we know we are all more than capable of getting the ‘work done’ and to standards required but then how do you manage the clients’ expectations.

   We develop web apps too and I always feel that because the client isn’t getting ’something they can see’ – a product in a box they always seem to have higher expectations do you find this? If I was to buy a Blue pen from a shop a week later I wouldn’t take it back and say actually I need it red and it ALSO needs to flash when I write? (After writing that sentence I feel somewhat harsh – so possibly as a caveat it may be that we need to tighten up our requirements gathering)

   How do you manage their understanding that to make a website is actually not as easy as people think?

   My initial thoughts and good blog by the way I have been subscribed for a few months now.

   Eggsy

   Comment by James Heggs, Tuesday, February 24, 2009 @ 3:04 am

2. 

   I’d be willing to bet that the majority of engineers in other fields also deal with people issues more than technical engineering issues.

   Comment by Craig Buchek, Tuesday, February 24, 2009 @ 10:46 am

3. [...] post:  Agile Ajax » Are We Engineering bSoftware/b or People? » Pathfinder b…/b Share and [...]

   Pingback by Agile Ajax » Are We Engineering bSoftware/b or People? » Pathfinder b…/b « topsoft.us, Tuesday, February 24, 2009 @ 6:12 pm

4. 

   I don’t know If you read the “Top Ten Sofware Engineering Reports” presentantion by Ed Yourdon.

   You can see in the concepts the importance of people and process and that technology is not the key issue in software development.

   http://www.yourdonreport.com/index.php/2008/11/13/top-ten-software-engineering-concepts-v10/

   Comment by Hugo, Thursday, February 26, 2009 @ 6:16 am

5. 

   Science is always about increasing human knowledge. Scientists look at areas that aren’t understood, propose a hypothesis and then test the hypothesis with experiments. After rigorous peer review, we’re often left with formulas or processes that make very accurate predications.

   Having scientific knowledge is useful because we often develop theories on how something should work and then we test it (isn’t that Agile development?). Electron flow in semi-conductors arranged into logic gates forms the bedrock of computing and is firmly rooted in the physical sciences. However, is proposing a theory on how multiple processes can run on a collection of semi-conductor logic gates (or CPU chip), then testing that theory with an experiment called an OS kernel, an implementation of the scientific principle?

   When developing software, do you ever catch yourself saying, “In theory, we should be able to do X?” Then some software is built to prove it’s possible, often that software is peer reviewed (code review). As software developers, are we not very efficient scientists in our own niche scientific area, constantly hypothesising and testing? We’re probably fairly unique in that we end up selling our successful experiments as a product, that proves our hypothesis time and again!

   Generally, when science makes it’s discoveries and moves on, engineers take over and innovation follows. As software developers, we are using well understood, genuine scientific discoveries in new creative ways.

   I am a Computer Science graduate and I’ve argued here that I am a computer scientist. In my heart though, even though we push the boundaries of what’s possible with computers, I know my staff and I are really talented (wannabe scientist) engineers.

   Comment by Chris, Friday, February 27, 2009 @ 6:09 am

Leave a comment