Perhaps it is the Fred Brook's quotation that opens the article which caught my eye, or the references to the founder of my program at McMaster. In either case, a cord was struck deep in the primal engineer buried under my code monkey facade.
Whatever the reason, the article pulled me in and all the way through to its conclusion, and comments. The author has a great point, and that is "Is vs Should." Software development is a lot of things right now, and not all of them are virtuous. Cataloging and categorizing what we are is not essential, but deciding what we should be, and becoming it is. We need not focus on our failings, to proceed; we need only clearly define that, and head towards it.
What do I think software engineering should be? Is 'better' to trite an answer? Perhaps, but I feel too strongly about it that it will probably come out all preachy, and be discredited as biased.
As some know from my past writings I rarely shy from commentary, but the comments attached to this article have stayed my hand. The first was clearly from one who didn't read the article, and replied to the "what is" question without realizing that the article wished to move past the "is". The last comment (4th at the time of this writing) was simply frightening. I perceived him to be so full of arrogance the very arrogance I fear being associated with.
The last poster led me to conclude that he felt that all software development should be the purview of science, and that the rest is substandard, and those using and creating it were neophytes. Furthermore, he seemed to justify software flaws of his science aristocracy as mealy the failure of perfect science to interface with a flawed world. What I think the commented failed to realize is that Engineers create marvels of science that should be tribute to science, not scene as a threat.
From an early age, I didn't know it then, but looking back it is clear where I wanted to go. It was then I learned what an engineer was, and engineer is one who derives value from science. That sounds bad, and not what I mean exactly but it is hard to articulate. The purpose of science is to learn things, and expand our knowledge. It is discovery without focus, yes scientists have disciplines, and areas of expertise, and hypothesis that are proved or disproved, but the goal of science isn't better the lives of people, but to advance humanity. Many a scientist may never see a practical application of there work in there life time. In fact some work may never have a practical purpose of its own, but may act as a stepping stone to greater knowledge. Let me wax Newton for a moment:
If I have seen a little further it is by standing on the shoulders of Giants.
So if science extends our horizons, then it should continue, unfettered by the demands of society. The author of the comment seems to suggest that the scientists should be delivering the end user products to us, I argue contrawise that the scientist shouldn't constrain themselves to worrying about a product at all.
That is the place of engineers. We are the makers; it is as if we are participants in some grand literary review of the works of science. Our papers are your cars, you buildings, your cell phone calls traveling through the ether (which is at this time more true then ever before in history, but I diverge.) An engineer figures out where specific scientific discoveries fit within our society. I don't mean to restrict "engineer" to just those professionally trained, but to those who are making this sometimes non-intuitive connection between pure science, and practicality/functionality.
I'm rambling now, and I mean to cut it short. My point is, engineers need scientists, or else they would have no source of new knowledge to build new things. Scientists need engineers to give them the buffer they need to do pure research. Individuals can straddle both worlds, but it is key that both roles exists regardless of who fills them.
As I have carefully avoided my stance on Software engineering, I will say I agree with the author of the main article, and hope people read it, and understand a little bit more about this crazy software world that I work in.