Software Engineering: Dead?

I was utterly floored when I read this new IEEE article by Tom DeMarco (pdf). See if you can tell why.

This is a companion discussion topic for the original blog entry at:
1 Like

Software engeneering is dead for people who do not work in groups > 4, groups who don’t need to maintain software over years, groups in military, medical or similiar live crititical environments… and so on. A stupid garage hacker can live without planning. If you would design something like the .net framework witout planning you can go home to your garage.

Tom DeMarco is good at selling ideas. And fit them to the buyers.

The bad thing is, that everyone in the business wants to get “agile”, without knowing that most of the problems are that the companies are not organised and have a completly wrong time planning. Only by SE you can try to get project times, try to plan a project. And sell it before you develop it to a customer.

I have seen a lot of companies that claim they are using scrum as process… but the sad trues it that most use it as excuse to be unorganised, over timeframes, over budget (or worse, don’t know what budget they need and buy new hardware and software every few month to get more performant, but do not see whats really going wrong)

I don’t really like the term “software engineer” (I’d prefer “developer” or “programmer”), but I don’t buy the idea of “software craftsman” either. What definition of “craftsman” are you using that would make it seem a more apt metaphor than “engineer”?

To me a craftsman means either someone who makes things using traditional tools (which certainly doesn’t sound like my job), or is someone who is highly skilled (which might apply to some programmers, but could as well apply to engineers of any sort).

The only discipline programming resembles is mathematics, but somehow I don’t see “software mathematician” catching on.

I have a massive problem with this: “…what we do is craftsmanship, not engineering”.

This is a massive thread, so I’m going to apologise if this is a point that’s been raised already.

What sort of engineer doesn’t have to carefully balance the best solution for a problem and its context? What sort of engineer doesn’t strive to suck just a little less? What sort of engineering department would tell you that there isn’t a better way of doing thing?

Not a great one- probably not even a good one.

Oh, and all that stuff about ‘yeah, but, if you’re designing a bridge then there’s only really one way to do it, you know, so, software’s so much more a craft than that essentially thoughtless and rigid structure engineers have impressed upon them’: Try pulling your head out of your Web2.0-hole and designing something critical.


I think you’re all missing the point.

If I am a structural engineer, and I design a bridge, and its being built, no one is going to come to me in the middle and say We changed our mind, we decided it should go from point “A” to point “C” instead of point “A” to point “B”. Or, we really need a bike path on it. Or, it appears that our traffic projections are wrong, we need it to be six lanes and not four lanes.

However, that stuff happens all the time with software. I start writing an application, and the specs suddenly change. It needs to talk to a new service. It needs this feature. We need it to talk to an iPhone app.

There’s no way to “engineer” an application like we use to in the old days. Change the specs? Hey, maybe we’ll do that for the next revision which we plan to do in three years when that new version of Fortran comes out.

It is impossible now to draw up a complete spec for an application, and then program according to those specs. You simply cannot “engineer” an application that way. By the time you finish, it’s obsolete. Your competitors have already claimed your user base. You’re out of a job.

The best you can do is have a “general direction”, and start coding before you even have the specs formalized. You work on a few major features, put it out there in the world, and then see how to move from there. Hmmm… Looks like Friendster is popular, maybe I should have an interface with that… Wait! No use Myspace. No Facebook. Aw, to hell with it, just have it send out some Tweets.

“Software Engineering” never existed. Developing software is nothing like actual engineering.

1 Like

IMHO, software engineering is not and has never been dead. It has evolved over the years, following technology and paradigms shifts
As already noted above, roles still apply for developers, programmers, architects…
Feasibility, Investigation and specification phases are crucial to any major sw project. Don´t see those as craft activities…
As for control and management, agile methodologies have prove to be efficient in following-up project evolution and flexible enough to correct any issues on-the-fly.

You mean, I’m not alone?!

Wrong. What does ‘engineer’ mean? It comes from the latin word “ingenium”, which means “cleaverness”.

Now think about these 3 professions: Architect, Civil Engineer and Industrial Designer. In all of them you need to know about scientific stuff (math, physics, etc.) but you also need some degree of creativity.

You wouldn’t call those professions ‘crafts’ because they involve quite a but of knowledge, not just skill, and ‘craft’ is mostly artistic.

Perhaps engineering is not the right word, but it’s better than craftmanship, at least you need to be more ingenious than artistic to be a “Software Engineer”.

1 Like

Now that you’ve given up on calling yourselves engineers, the rest of us actual engineers can stop trying to defend our profession.

1 Like

Jeff -

Thank goodness there is still actual software engineering behind the fly-by-wire control systems on modern aircraft. Apparently, strict demand for correctness can be achieved if it’s important enough to be right, or costly enough to be wrong. Same story for cars, trains, and ships. In those products proper engineering will demand software to be just as testable and reliable (with mensurable failure rates) as the physical components (ailerons, tires, etc.).

  • Lpeto
1 Like

Amen. I couldn’t agree more. Programming is a creative, iterative and experimental process.

There is a certain subset of programs that can be engineered; these are problems that have been previously solved, have very fixed parameters and simple component integration. I don’t think this covers many situations (certainly very of the ones I’ve worked on).

Software engineering projects can require from little to very high levels of “ingenium” and “cleaverness” as well as challenge the barriers of math, physics and creativity.
That is the case of embedded systems where limited resources and tight integration with hardware are required.

I think the problem is that ‘software engineering’ as such has come to be dominated to a certain extent by a mongrel breed of half-assed bureaucracy which has gotten away from software, the thing itself, and which is why, of all the things on the To Do list for a piece of software, the software itself is likely to be towards the bottom, at least from the perspective of the people who pay the programmers to write the software. Which is why it’s so important to be a craftsman; in the teeth of that kind of well-hey-lets-just-use-VB6-then bureaucracy.

It saddens me that thisis the case, but in my experience it’s also true. I have never seen engineering principles carry even a moderately complex project through to success in the absence of genuinely passionate developers. Yet I’ve seen passion create amazing software without a heavy engineering process time and time again. I firmly believe that skilled, passionate devs will naturally create and follow an effective engineering process without intervention simply from a desire to create. Deadweight devs, on the other hand, will never create profitable software no matter how much process you throw at them.

Don’t worry Jeff, you’re not a software engineer… You’re just a VB noob.

Or C++ shudders even worse.

I have maintained for years (and nothing has changed my mind yet) that software development is all about the people. If you have good people around you, people who care, who have courage and integrity you will succeed no matter what.

I think that is what the spirit of agile is all about, it’s not pair programming or refactoring (those are just a means to an end) it’s about the people, the environment and how they interact, it’s about getting everyone just a little bit personally invested in the success of the project. That doesn’t sound like any sort of engineering I’ve ever heard of.

1 Like

This just makes me wonder if we haven’t really gotten started yet. While I do totally agree that conventional engineering principles don’t really apply to software development (do they apply to the construction of any complex system?) there is definitely a place for rigour in our discipline.

For example, how much better has both QA and testing become as we learn and understand more about the field.

Likewise we still need to take into account, things like medical systems which require sophisticated controls to prevent faults from slipping through the process.

That said, the development itself still needs to be iterative to keep things moving quickly.

– Lorenz

1 Like

“Project A will eventually cost about a million
dollars and produce value of around $1.1
million. Project B will eventually cost about a million
dollars and produce value of more than $50
What’s immediately apparent is that control is really
important for Project A but almost not at all
important for Project B.”

Why isn’t control almost not at all important for Project B? Just because it is going to make a huge profit? How do you guarantee that your project is of type Project B. In the beginning you can think that it is of type Project B, but what if later it turns out that it has become of type Project A and you have completely neglected all control up to that point?