While listening to an episode of the .NET Rocks podcast on my commute, as is my wont, something that guest Doc Norton said really resonated wtih me.

Software development isn’t “engineering,” it’s research and development.

  • Doc Norton

The way software development projects are estimated, funded and run is almost always approached the same way an engineering project would be approached. The problem with this is that engineers building something concrete (like literally building something out of concrete) can measure, design, and implement exactly the required structure to address whatever issue they’re facing. Need a bridge to span a river? You can measure exactly the width of the river, measure the weight of the vehicles that will need to use the bridge, come up with a design, run a simulation to make sure the design works, and then implement the design exactly as specified and be reasonably sure the project will be a success.

Meanwhile, software projects often times have just a vague idea of making some process “better,” “faster,” or “easier,” with no fixed requirements, and not even any fixed point at which the project can be called complete. These are not engineering projects, they’re research and development. We’ve tried bolting some things on top of this engineering approach, like the Agile methodology, with it’s scrums, sprints, and story points. Extreme Programming has a lot of similar ideas, with lots of iteration and user acceptance testing.

These things are all attempting to deal with the fact that the Waterfall model doesn’t work for software development, but really, what we’ve done is make new words for research and development concepts like prototyping and focus groups, while still trying to maintain the illusion to our customers and bosses that we are engineers.

The problem is that when customers and bosses think of us as engineers running engineering projects, they expect us to be able to estimate, design, implement, and measure the success of the project as though it was an engineering project. This doesn’t work because almost all projects have shifting requirements and are often never truly “finished.” Your process can always be better, faster, stronger. You have the technology.

Calling yourself an engineer is seductive, because it makes you sound professional and can guarantee the success of a project, but it’s a lie. Setting expectations up front that a software development project is an R&D effort and not an engineering process helps set expectations on all sides as to how every aspect of the project is approached, and ultimately whether it will be a success. That’s why I maintain the title of Developer on my resume and professional correspondance.