I used to think that there was a full-fledged field of software engineering out there, that is to say, that software engineering is a branch of engineering discipline.
This is not quite true.
After some years of observation, personal research on the history of computing and based on the work of other researchers like Alistair Cockburn, Craig Larman, Pete McBreen, my understanding of some David Parnas’ papers, and some other opinion-leaders and practitioners in our industry, we are making ourselves a disservice pretending software development is a branch of engineering discipline and taking decisions based on such assumption.
“If you call a tail a leg, how many legs has a dog? Five? No, calling a tail a leg don’t make it a leg” -Abraham Lincoln
There are aspects of ‘engineering’ our industry really needs, those around professional masterity based on experience, the kind of behavior and thought process exhibited by professional practitioners in action.
Instead, what have been seen within typical ‘software engineering’ environments are paperwork-oriented processes, exceedingly expensive and bureaucratic projects, and a self-important attitude in front of users and customers.
There are people (usually non-current practitioner programmers) who are defining their perspective of what is or has been a so called “software engineer”, but their perspective is based on unacceptable conclusions derived from improper analogies with engineering disciplines.
See for example:
A simple notion of an engineering discipline is the application of science to solve practical problems in an economical and social accountable way. My point is that software development is a human activity not yet on that simple notion. Please consider the facts of the history. Please consider even the “Working Conditions” section of the web page above.
Looking upon the properties of software, software writing (also known as logic articulation or reasoning communication or “software development”) should not be considered an activity subject to be administrated by the principles of Taylorism (Principles of Scientific Management by Frederick Wislow Taylor,1856-1915) of mass production and process automation, as many engineering disciplines have typically achieved their economic properties. Interesting enough, they have acquired significant knowledge and values, principles and practices that depart from such a perspective, see for example lean manufacturing, just-in-time manufacturing, and in general the kaizen philosophy of continuous productivity improvement.
At the same time, in some sectors in our software industry people are mislead by incorrect assumptions, going backwards instead of stepping into new insights of the peculiar human-orientation of our singular activity.