Less than Engineering, More than Engineering
It's the "soft" in software that should make you wonder if you're really doing "engineering".
The American Engineers' Council for Professional Development defines engineering thusly (thanks, wikipedia!)
“[T]he creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.”
That certainly sounds a lot like what I do when I write a program. Certainly I try to apply principles from my Computer Science education to create programs that I believe are essentially machines. But is that really all we expect from engineering? It seems to me that Software Engineering as a discipline is very different from the other engineering disciplines.
Software Engineering lacks a prescribed transparent process for creating quality software quickly. An engineer constructing a bridge for a highway knows what materials are necessary, what design is necessary, and roughly how long it will take to build that bridge. If the design of the bridge doesn't result in a bridge that has all the required properties, we don't blame the discipline; we blame the engineer.
But Let's face it: no software developer can give an accurate estimate of some unit of work unless he's done it before. And if he's done it before, why is he doing it again, instead of re-using it? The best estimates will come from work that's closest to something he's done before, and where the task differs from that previous task is where we find the estimates becoming less reliable.
Software Engineering fails time and time again at providing the kind of manageability that other engineering disciplines do. It's more uncommon than not for software projects to be buggy, behind schedule, and over-budget.
Maybe it's the relative youth of the discipline of course, but anyone that keeps abreast of development methodologies like XP, Agile, Scrum, BDD, TDD, etc knows that we're still not converging on something common, and knows that there is no silver bullet . It certainly seems like most of the development shops still using the waterfall model are the ones that haven't learned the other more fashionable methodologies yet. BDUF is making way for YAGNI.
Software development talk is rife with metaphors, but one I've always really liked was Paul Graham's likening of writing software to painting. I honestly don't feel like much more of Software Engineer than I would consider Picasso to be a Paint Engineer. There is an *art* to it. There's something unquantifiable about it, and it seems to me like it's no mistake that Mr. Knuth chose to name his tomes on Computer Programming accordingly. A good program is not just the sum of a combination of best practices and design patterns.
It doesn't serve us well to be looking at software like something that can be "engineered", as if we can design something correctly up front and have a good idea of the effort required to create it. It doesn't serve us well to call ourselves "engineers" as if we have the ability to completely understand a piece of software and the process to create it before it exists. I realize that this makes software development management difficult from a business perspective, but we can't alleviate the problems associated with this reality without first admitting it exists.
Don't get me wrong -- I'm still grateful that we're pursuing the goals of manageability, maintainability, estimate accuracy, quality, development velocity, etc. I think about these things more than anything else. I'm grateful that we're talking about things like design patterns, best practices, refactoring, coding standards, version control, all the forms of testing, release management, change management, documentation, requirements gathering, etc, etc. This conversation is how we all get to create better software. This is how we make our process faster and better.
But a moderately experienced developer who cares about his work can always produce better software in less time than a lifelong student of Software Engineering who's never written a line of code. There's an unquantifiable knack to it. Let's not fool ourselves: What we're doing is something different from engineering.