Why Software Engineering Isn’t Engineering
blog.iancackett.com
Why Software Engineering Isn’t Engineering
1–10 of 59 posts
Re: Why Software Engineering Isn’t Engineering
#2His argument against calling it "engineering" is because we don't properly estimate our time?
To me, engineering is a way of thinking, it's all about problem solving.
Re: Why Software Engineering Isn’t Engineering
#3This is possibly the silliest post I've ever read. Apparently you don't know the definition of engineering and, most astonishing, claim building projects are always perfectly estimated. I doubt ANY building project ever finished on time or under budget. If everything were tidy and well understood, it wouldn't be engineering. Stick to software, Ian.
Re: Why Software Engineering Isn’t Engineering
#4We've been talking about this for over forty years now and it just hit me - engineers are categorized by what they build whereas software engineers are categorized by what they build with. If you asked an engineer who's an expert at building bridges to then build a skyscraper, they're likely to have estimates that are off-base. Meanwhile in the software world we say we're Java developers or Ruby developers or Haskell developers are whatever. The field is only now starting to really mature to the point where we can start categorizing different kinds of software projects and specializing in different practices.
Re: Why Software Engineering Isn’t Engineering
#5So I decided to search the definition of engineering on the internet because I've heard this whole "software engineering is not engineering" thing before:
> Engineering (from Latin ingenium, meaning "cleverness" and ingeniare, meaning "to contrive, devise") is the application of scientific, economic, social, and practical knowledge in order to invent, design, build, maintain, research, and improve structures, machines, devices, systems, materials and processes.
So, software "engineering" definitely involves the use of scientific, economic, social and practical knowledge to build, maintain, research, and improve devices, systems, and processes. So that, in my lowly opinion, makes it engineering "in the strictest sense of the term".
Arguing about semantics is extremely stupid if you are not a PHD in linguistics.
Re: Why Software Engineering Isn’t Engineering
#6"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case."
Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more public works projects shared the "surprise factor" of software projects. I'd recommend Caro's "The Power Broker"[2] for a fascinating history of NY-area public works (among other things - great book all around), including how much of that process was about adapting the plan to new things the builders were learning along the way ("oh, turns out that soil is completely different than we planned...")
That's not to say that there aren't particular features that make software engineering its own special snowflake - as there are meaningful differences between how civil, structural, mechanical, etc. engineers operate. But spend some time in another engineering organization and you'll find it's different, but not as different as you think it is.
(And FWIW, even civil engineers sometimes follow "agile" concepts - a company I once worked for was contracted to design a highway, and even after the construction started, engineers were "embedded" with the builders to make on-the-fly adjustments based on the environmental factors they discovered throughout the process... I wish I could find their project write-up, but it was a while ago and the company has long since been gobbled up by a bigger company).
* As a (subjective) kicker, I'd add that the Big Dig, over-time and over-budget as it was, was ultimately quite worth it... much like many software projects!
[1] http://en.wikipedia.org/wiki/Big_Dig
[2] http://www.amazon.com/The-Power-Broker-Robert-Moses/dp/03947...
Re: Why Software Engineering Isn’t Engineering
#7Building a bridge of a million bricks - most of them do the same thing. A software project may have a million moving parts, all of them doing different things. The comparison is silly.
I'd use the original moonshot as a better example. It was hugely complex, unpredictable, late, had a large number of last-minute problems. They essentially used Kanban to solve it - hanging a drawing of the rocket on a large conference room wall, and taping notes to each place where there was a problem; reviewing each note at a 'scrum' meeting each morning.
So Engineering has been working this way for at least 50 years. There's nothing to see here folks; move along.
Re: Why Software Engineering Isn’t Engineering
#8Wow, so, Hacker News... didn't see that coming.
Thanks for the comments, good and bad, folks.
One thing I certainly agree with: Regular physical engineering isn't entirely free of many of the problems I mention with software engineering, but the ability to understand and plan more effectively does appear to be there. The complexity in physical engineering does seem to be a little more tangible. I know a few civil and mechanical engineers, so I'm not plucking this from my behind ;-)
In terms of the definition of engineering, and the argument that software engineering isn't "engineering", I was taught this way back at university (City Uni, London), in their Centre for Software Reliability, and it's something I've largely agreed with. However, I think it was mainly used as a warning mechanism for newbie software "engineers" like me, to let us know that what we do is significantly different from other forms of engineering, in terms of the rigour. Perhaps it still deserves the title, but I guess that's a longer discussion.
Re: Why Software Engineering Isn’t Engineering
#9This is possibly the silliest post I've ever read. Apparently you don't know the definition of engineering and, most astonishing, claim building projects are always perfectly estimated. I doubt ANY building project ever finished on time or under budget. If everything were tidy and well understood, it wouldn't be engineering. Stick to software, Ian.
Having studied Software Engineering as a degree, I can assure you they teach software engineers the definition of "engineering", and stress that we are practicing something else or, at a stretch, an extension of engineering somewhat different from civil or mechanical. I realise that building projects probably suffer from many of the same weaknesses, but the degree of rigour, and ability to reason about the project, is definitely way higher than on software projects. I knew a few civil, mechanical and aeronautical engineers, and they tend to agree. That said, definitions like this can be hard to pin down!
Re: Why Software Engineering Isn’t Engineering
#10>projects delivered precisely what they said they would, and in the timeframe they originally promised.
Those factors are "project management" which include concepts like "scope", "budget", and "critical path".
It's arguable if those are "engineering". They certainly affect engineering. (And likewise, some engineering constraints can feed back into project planning and feasibility.) In any case, project planning is a separate area of study. Using the author's strange definition of "engineering", it means the NASA Space Shuttle is "not really engineering" because it didn't deliver to the specifications of 50 launches per year at low cost.
A more reasonable definition of engineering that most could agree on would be, "the study (or art) of balancing technical tradeoffs against real-world constraints".