Software Engineering: Dead?

blog
208

It was always a mistake–except possibly as striking rhetoric–to speak of “software engineering” alongside “bridge engineering”.

Bridges can truly be engineered in that there is a small and fixed number of solutions and the engineer’s task is to apply whichever solution is appropriate to a situation. The software equivalent is not writing a web application or browser extension but porting gcc to very slightly different platform.

If we translate the other way from software to bridges, then the equivalent request is to build a bridge with two or more endpoints, where one or more endpoint can be crafted, and halfway through construction requests will come to hang motel-like rooms on the sides of the bridge.

Such a “bridge” cannot be engineered, even if one could undertake the risky proposition of trying to invent it. The engineering work in software is handled by COTS and Freshmeat acquisitions; if a team of developers is asked to do it, then it’s probably not something that could be engineered in the first place.

I’m glad we don’t have software engineering: if we did, most of the work that draws me would be dead.

209

@Jonathan Hayward: Of course software is different in nature than concrete constructs. But that doesn’t mean that we shouldn’t try to make software construction sane and efficient. Both buildings and software have different kinds of projects, in some people create tools and in some end products.

At the same time in architecture the architect is a kind of an artist. There exists many fancy looking buildings. But even the fancier buildings have been engineered more or less.

There are also software projects that try to create something big but fail. Maybe they didn’t realise all the dependencies beforehand or something. But they could have used some strict principles to improve the design and construction process to begin with.

Artists and crafters have more room for creative mess than engineers. But big software projects cannot be playgrounds of creative mess. Some creativity can exist eg. in the specification level and inside modules, but in general the construction should be orderly and standard. Even if every function is different, there can be a standard of naming the functions.

For example I don’t want to hear like “hey Jack, are these documents up to date?” nor “there are no documents of this?”, because in engineering of course the documents should be up to date without asking. In software development it is often more like “who reads the manual anyways”-attitude, but that doesn’t work in bigger projects and in larger scale of things.

211

Please, go purchase and read Roy Miller’s, “Managing Software for Growth (Without Fear, Control, and the Manufacturing MIndset)”. It is a small book that on par with Peopleware and The Mythical Man-Month. It is in the Software Engineering section, ironically. Guess you have to attack from within.

/s.

212

I am not a fan of software engineering and i do think that “passion always creates good projects” without heavy engineering them.
But that’s just not true for all kind of software.
History can offer so many examples: the Linux kernel, is the result of passion. But a lot of critical “pieces” have been designed, analyzed and discussed before typing C on a keyboard; software for online banking and trading have a lot of engineering inside; avionics software (thank god) has a lot of engineering too.
I do not understand why a civil engineer is a must to build a bridge and a software engineer is not even considered to build a critical system.
I don’t agree with the conclusion “Software Engineering is dead”. That’s just a polemic conclusion.
I’d rather say “it depends”, as a good engineer would say :slight_smile:

213

I think the reality today is that software is not an engineer science, at least in my own experience. I have never been a project where, after having the 80% work done, a lot of the initial requirements were changed. How you could manage this in an engineer discipline? Again, with the example of the bridge, I can’t imagine the engineer of a new bridge to accept changing the design of that bridge when the work is 80% completed. This is the huge difference.

Perhaps one day “computer engineering” will be a reality but until then, what we do every day is craftmanship.

214

I think the reality today is that software is not an engineer science, at least in my own experience. I have never been a project where, after having the 80% work done, a lot of the initial requirements were changed. How you could manage this in an engineer discipline? Again, with the example of the bridge, I can’t imagine the engineer of a new bridge to accept changing the design of that bridge when the work is 80% completed. This is the huge difference.

Perhaps one day “computer engineering” will be a reality but until then, what we do every day is craftmanship.

215

"Physical solutions are built upon immutable knowledge - the tensile strength of steel, the conductivity of copper. There is nothing immutable about software."
Have you ever consider the fact that software runs on hardware therefore software inherits / is constrained by most if not all of the host hardware’s so-called “immutable characteristics”?

216

“How you could manage this in an engineer discipline? Again, with the example of the bridge, I can’t imagine the engineer of a new bridge to accept changing the design of that bridge when the work is 80% completed. This is the huge difference.”

When a bridge is in CONSTRUCTION, the Engineering Design is completed.
When a piece of software is being CODED, the Engineering Design ideally should have been completed.

Yes you can craft software without Engineering Design, just like you can craft a bridge without Engineering Design, as long as the customer is willing to accept the potential faults and defects.

Really. Should we say ALL engineering disciplines are dead because if you are crafty enough you CAN build anything without engineering design.

I think the reason why we have this discussion here is because everyone and their dog calls themself Software Engineers as soon as they can code Hello World.

217

If you ask me, the “death of software engineering” really means that the average software application has become little more than a trivial time-wasting web site, an unnecessary toy for the rich, rather than anything socially important.

Imagine I’m writing the software that controls the Airbus A380 that’s about to take you out over the ocean, or the medical device that’s about to shoot gamma rays into your head to treat your brain tumor. Would you prefer I adopted a casual non-engineering approach to my code? Let’s dispense with unit tests and code reviews, after all, it’s only software? Let’s try out some new untested ideas and “see if they fly”, literally?

I dropped out of college in the 80s to write software. Back then, we thought software was a revolution that would change the world for the better. Instead, I’ve spent the past 25 years helping companies get rich selling junk to rich kids. It’s very sad.

218

I just hope that ehsanul and others who made similar comments never work on any safety-critical systems - fly-by-wire control software for passenger aircraft, for example!

I then to think that everything Tom DeMarco said was prett correct except for two bits: the idea that software engineering is useless or dead (as opposed to the control-freakery the “engineering” word has been used to justify) and his link to “Agile” (which is just another boring rehash of stuff that all competent software peopel have known since the 1960s or maybe earlier, with the usual added soundbites intended only to make it look like something new but actually encouraging the empty suits to impose yet more stupidity on the real developers.

219

an interesting article, but in my little corner of the software world, I don’t think that is true.

I have been trained as a hardware electronics design engineer and am recently writing code for an embedded platform, and I see very little difference in engineering one or the other.

Using software libraries to build code is very similar to what I would do in the hardware world, building schematics, laying out PCBs and manufacturing.

The only difference is that the software cost nothing to put right when a mistake is made.

I can’t really comment on the ‘soft’ area of software as I have no experience in it.

220

Keanu Reeves and Tom DeMarco quoted in the same article. Whoa.

1 Like
221

Not sure I agree with DeMarco’s conclusions. From the final paragraph:

"For the past 40
years, for example, we’ve tortured our-
selves over our inability to finish a soft-
ware project on time and on budget. But
… this never should have
been the supreme goal. "

That’s completely unrealistic for most businesses. In fact, most software projects are failures, not because they can’t be done, but because they can’t be done within the constraints provided. Just look at the infamous “failed” Denver Airport software example. It’s not like it never got done. It merely wasn’t complete by the expected date.

If, like Stackoverflow, you have essentially infinite resources like time/money, then having “metrics” are irrelevant. Now, I know you guys didn’t literally have infinite resources, but your project took twice as long as expected and it didn’t matter. Most projects are not in a position to absorb double the expected cost. I’d say these kinds of projects need some type of “software engineering”.

222

Great. On one side of the camp, we have the circle-jerk of self-centered geeks aggressively misquoting and editorializing authority figures in order to “prove” that they can’t be actively managed, and on the other side we have mindless drones throwing out the same tired buzz phrases like “agile” and “best practices”.

Can we please have some sanity?

Tom states, in no uncertain terms, “I still believe it makes excellent sense to engineer software.” When he disparages software engineering (and he never says “dead”, very irresponsible of Jeff to make that attribution), he is CLEARLY talking about the actual institution of software engineering that is actually project management and obsesses over metrics and controls. He is NOT saying that you shouldn’t apply engineering concepts to software, and he is DEFINITELY not saying that development is a “craft”.

As usual, the waters are being muddied by people with no engineering education or experience whatsoever, people who are not even remotely qualified to comment on matters engineering-related. When an actual expert writes something that looks, superficially, like the message these egotists want to send, they take it completely out of context and say that “a crushing weight has been lifted.”

I’m in software by trade, but was educated as an engineer, and I can tell you that they are EXACTLY the same. All engineers have to deal with vague requirements, scope changes, scope creep, faulty components (materials), clueless management, project failures, process failures, experimentation in general, and vast differences in competency. That’s engineering. That’s what engineers do.

The real message from Tom is that these suits who co-opted the term “engineering” to create a project management discipline have their heads up their asses. The ISTQB did the same with “testing”. This abuse is all over the place. The only worse travesty in my opinion is when somebody reports it as the norm and uses it as a straw-man argument against the actual, legitimate ideas.

223

It seems that most people here don’t even understand what Software Engineering is. Forgive me if I read the first few comments and skipped to the end, but SE is not about “putting your head down to code”. It’s actually as far from that as possible.

Software Engineering is not a descriptor of how passionate you are about your work; to claim that “craftsmanship” and “engineer” are a contrasting duality is naive. Engineering is about how much responsibility you take, planning you perform, risk you assess, your methodology of requirements gathering, and more. They are part of engineering because they are truly quantifiable/measurable properties. In fact, the only truly “crafty”, “creative” part of software development is when you sit down to write code-- but any good developer will tell you the code is only the “20%” of the process.

If you want to call yourself a craftsman, fine; but what you’re essentially doing is calling yourself a glorified codemonkey. Someone who might be great… at only 20% of the software development process.

224

Great and when your craftsmanship crashes because of poor design, testing, implementation and usability I will still feel safe and secure knowing it’s not an engineering problem. Why is software any different from hardware engineering? That’s not a craft. When you build something physical it has to do the job and not crash. When you build lines of code you can just patch it so it doesn’t matter?

What the article is implying is that you can’t impose engineering principals on guys wbo couldn’t do engineering in the first place…

225

I never use the term “engineering”, I prefer to use “development”. I code for fun, and if I can make money doing it, awesome. Most of my software is being released free on my blog ( http://jeffhansenonline.com ) and on Youtube. It you brings joy when you get comments, telling you how great your creation is.

In my country, knowledge and technology is our main export.

226

We can’t predictively measure or control some of the most important aspects of a software development project, and if we try, we soon discover that the “observer effect” from physics applies to us as we end up changing the thing we’re trying to measure (and inevitably not for the better). The best we can do is to anecdotally evaluate how we’re doing by considering our past, inspecting our results, fast track cash review, and making course corrections for the future.

227

Not sure how I stumbled upon this old thread… but i’d figured i’d chime in 4 years later…

Its 2014, and Software Engineering is not dead. Anything attempting to create a repeatable and predictable process will NEED an engineering based approach. Agile with estimates is only as good as the accuracy of the estimates…

define your process, enforce your process, measure your process, predict your process, improve your process… how the hell can any of those concepts ever be dead???

Software Engineering is not about the code that’s written, it’s about measurement, improvement and accuracy…

-MSSE

228

Summarize time (in deep retrospect)! S3 the button and @Paul_Nathan there… Except I got a very different overview:

  • Software Engineering as paper planning before computer executing, is dead. Engineering as being cleaver or a craftsman, is obviously not what either Jeff or Tom meant. People won’t die if you’re not making medical software in paper before the computer. Just plug the software on people when it’s ready, evidently. It does involve both creativity and correct practice.
  • Software development in general terms is about people. Thanks @AlanS
  • “Building” an app is a broad enough term that can include it being an art, sure. And code can be beautiful in many different ways. Do google for piet programming.
  • Keanu Reeves’s Whoa is virtually in any article opposite to Homer Simpson D’oh. Not a big surprise it ended up with DeMarco. It was bound to happen eventually.

Next topics in the chain of evolution from this general agile thought, from my own lingering memory and non-complete blog reading:
2010 Go That Way, Really Fast
2012 Todon't
2014 Three Things

Maybe the same way I did? From meta discourse. It also brings a great @sam_saffron quote:

One thing I learned working with Jeff is that often the need of complex todo lists and kanban boards is lack of focus and direction.