Footsteps echo through the empty hallway as you stride, coffee in hand, toward your study. You cross the threshold, briefly pausing to flick on the overhead lights, and the laptop on the center table stares back at you, the schematics gleaming on its too-bright screen. Setting the cup down, you study them one last time, looking for any errors or miscalculations that you might have missed previously. It's taken many late nights, but finally, finally the plans are ready for the customer's approval.
Taking a sip of the still-scorching coffee, you go over the customer's requirements one last time. A breakfast nook? Check. Four bathrooms, one with a ceiling-mounted rainfall shower head? Check. A three-car garage and expansive yard? Check. Everything's there, everything's in place. This final review fills you with confidence; surely the customer will be pleased and construction can start right away. You close the laptop, grab it and head out the door, eager to present your plans to the customer.
Just as you expected, the customer is thrilled! He's very happy with the size of the yard, and knows he and his family will make good use of the swimming pool and breakfast nook. There's just one little thing....
"Can you make it fly?"
Craftsmanship, Not Engineering
The story above is preposterous; no right-thinking person would ask for a house to fly, because they've seen houses before and none of them flew. Yet such a scenario happens all the time in software development. The customer asks for something he thinks is reasonable, but to us developers it may be completely impossible, at least until we figure out that it isn't. There are few rules in development, even fewer agreed-upon standards. We can, and usually do, build anything as long as it matches the customer's expectations.
A few years ago, there was a big debate about whether or not software development could be called software engineering, and it arose from a paper titled "Software Engineering: An Idea Whose Time Has Come and Gone?", by Tom DeMarco. DeMarco argued that software engineering was dead, lived a short life, and indeed was not vital or even necessary to the creation of what he called "transformative" software.
DeMarco's paper posited that because of the lack of measuring ability (and the incredible depth and breadth the term "software" has come to represent) software engineering had died. I see a different problem: software engineering never existed.
For the record, I agree with Mr. DeMarco on his major point. Software development is not engineering, because in traditional engineering outcomes can be measured and controlled for repeatedly and with confidence. DeMarco's famous quote of "you can't control what you can't measure" is a perfect summation of this idea; if you cannot measure the impact your changes are having, what hope can you have to control for them?
This, as I see it, is the primary reason we cannot call software development "engineering": we can't measure the impact our changes are having. Sure, we can unit test and integration test and do all the other tests we can think of, but we cannot accurately estimate the scope of all the effects our potential changes will have when we want to apply them to an existing system. We simply don't have the tools to do this, and IMO we never did.
I have come to think of software development as a craft. The term "craftsmanship" better describes what we developers actually do.
The primary difference between craftsmanship and engineering is that the latter uses widely-known and accepted knowledge to solve problems, while the former uses more specialized knowledge that is not so widely held and probably not codified or generally agreed upon. Therefore, we can make the argument that software engineering never existed, since there's not enough commonly-accepted knowledge in the field to justify calling it "engineering".
But could software engineering exist? And would it even be useful?
Could Software Engineering Be Workable?
Assume, for a second, that it is even possible to transform the entire diverse field of software development into engineering disciplines. Would we actually want to do this?
IMHO there is some level of artistic skill involved in creating usable software, some form of creativity that cannot be accurately represented by mathematics or engineering. That creativity is what enables us to come up with novel solutions to problems we've never seen before. It is also something that can potentially shoot us in the foot if we're not careful with it.
It seems to me, then, that making software development an engineering discipline removes a lot of that creative freedom (though, admittedly, not all of it). Reducing software creation down to a set of rules and figures hampers our freedom to think laterally in trying to find a solution to our current problems.
On the other hand, using engineering strategies significantly improve ideals like standards, testability, and project management. Further, it provides a common pool of knowledge that we can use when referencing our solutions, making them easier to cross-reference and use as sources.
Still, would all that knowledge sharing and control be worth the tradeoff of losing some creative freedom? I'm of the opinion that it would not be worth it, even if it were possible. Software can be used for basically everything, and the great lateral freedom we have in solving problems is much more of a boon than a hindrance. There's too many variables, too many problems, too wide a scope of potential issues to even consider trying to shoehorn all software into engineering. Using engineering strategies for all software development would be a disaster.
The story at the beginning of this post illustrates a common but incorrect assumption when comparing software development to engineering: that designing software is like building a house. This couldn't be further from the truth. A house is tangible, subject to physical laws like gravity and built using historical experience humanity has gained from needing a place to live for thousands of years. Software is none of these things, and making this comparison is ingenuous at best and downright dangerous at worst.
In short, software development will never be software engineering.
Our profession is a craft, and we are the craftsmen. It is a process by which we programmers take specialized information, particular to our project, and design and implement a solution that satisfies our customers' needs whatever they are. It is art, it is creative. It is not engineering, and it doesn't need to be. We should be OK with that.
What's you opinion? Do you think striving toward software "engineering" for whatever that means is a worthwhile goal, or an impossible one? Share in the comments!
