7 ms·

Software Engineering: An idea whose time has come and gone?

69 points by swombat 17y ago

edw519 17y ago
The critical flaw of the Systems Development Life Cycle has always been that you needed to define your outcome before you started development. It was inevitable that modern tools and technologies would turn that process around, that development itself would be used to determine requirements. So now, when you start development (according to the old rules) you already have lots of work done. Does this mean the software engineering is dead? Hardly. It's just evolved to what always worked.
swombat 17y ago
Excellent article, very well put imho. It's interesting to also look at this as an argument for more modern, rails-like dynamic frameworks that enable the transformative result rather than trying to control programmers.
mingyeow 17y ago
What an AWESOME posting. Cannot upvote this enough. Balancing focus and diversification in portfolio is definitely the key to success. Rock on!
DanielStraight 17y ago
I love this quote: "I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product."
stonemetal 17y ago
Project management != Software engineering As a truism Software Engineering is the act of engineering software. Managing the project that is supposed to engineer that software isn't Software Engineering. As long as we are building software larger than a page or two long SE will be important.
marksutherland 17y ago
The majority of this article tackles the over-reliance on software metrics, an issue that many people have brought into question over the last decade or so, and he does a good job of summarising the problem with it. However, in the last two paragraphs he attempts to tar the rest of the Software Engineering discipline with the same brush, painting it as a set of overtly rigid tools bureaucratic managment might use to crush the life out of any software project. I've studied as a computer scientist and as an engineer (electronics) and it's been my constant impression that those trained in the former completely misunderstand the latter. The engineering mindset is one of creative problem solving, using heuristics, tools and systems that have worked well in the past to guide you to your eventual goal, and ignoring them if they don't make sense or will misguide you. Instead many programmers seem to want to find the general algorithm for development. It doesn't exist and in a way its our philosophers stone, it's pursuit wastes time, effort and money. Instead we should be happy with the ever expanding toolkit of techniques the modern developer has at their beck and call whenever they're necessary. That's the real essence of Software Engineering, even if some parts of the industry have gotten lost over the past few decades. Frankly, this article's title is blatant troll-bait and I really should know better.
- smithjchris 17y ago
  It's by the IEEE. Most of these "elitist clubs" tend to knock out this drivel by the truck load to try and make their members feel relevant and manipulate the industry. Open Group, IEE (UK version of IEEE) are just the same. Fortunately, people just aren't interested any more.
  - ben_straub 17y ago
    It's by Tom DeMarco. The co-author of this: http://www.amazon.com/dp/0932633439 http://www.amazon.com/dp/0932633439
  - deleted 17y ago
    [deleted]
  - Kaizyn 17y ago
    If that's a majority view, then the dumbing down of the discipline is complete.
wglb 17y ago
This is an excellent article. I am not familiar in detail with DeMarco's work, but it is very refreshing to hear a pundit/consultant/authority say "I am uncomfortable with what I said before" after having learned from experience or history. He offers an excellent example of project characterization: "a $1m project with expected value of $1.1m vs $1m project with expected value of $50m".
- silentbicycle 17y ago
  DeMarco and Lister's _Peopleware_ is excellent, IMHO.
raphar 17y ago
One problem with Software Engineering lies in the engineers themselves when they forget the time or money aspect of their designs. Your design may be perfect for the domain, but if the time you have is just 6 months, you have change your design to something 'buildable' in that time. I fall for this one when I got an interesting/challenging project. Given enough time, the ability of a S.Engineer to find diferent solutions depending on money/time availability will positively affect her/his pay. (and the size of the assignments)
- prodigal_erik 17y ago
  "A programmer is someone who, given ten days to complete a task, will spend nine days figuring out how to do it in one day."
forgotmypasswd 17y ago
Lol. I just realized that the [scribd] tag was a separate link, and not a warning that the entire link was to scribd. I guess not everyone hates scribd as much as me.
- nkurz 17y ago
  I've had the same experience, and had been avoiding such links as well. Regarding your 'hate', though, it may be worth noting that Scribd is a Ycombinator company.
  - Zak 17y ago
    Are you suggesting that people should not express dislike of YC-funded companies here? I don't think we really want to encourage the creation of taboos like than here.
    - nkurz 17y ago
      No, I was suggesting the presence of links to Scribd may not be intended solely a convenience to the current HN audience. I do think there is some self-suppression occurring regarding YC companies, though. This is a good thing if it encourages more thought as to phrasing, and a bad thing if it creates a taboo.
gruseom 17y ago
Pedantic comments about usage of the word "engineering" are missing the point of this article. What's important is a guy who has been an industry leader for decades reflecting on what he, and the industry as a whole, got fundamentally wrong about making software. That's pretty relevant to anyone who wants to learn from previous experience. (Not everyone does, of course. A lot of software people appear to believe that the past, by virtue of the fact that it didn't contain them, is inherently stupider than the present.)
deleted 17y ago
[deleted]
geebee 17y ago
I'm of the camp that never wants to see the word "software" associated with the word "engineering." They're too different to be under the same umbrella, and I'm worried that the various engineering accreditation bodies will start to believe that software falls under their auspices, like civil or mechanical engineering. It would be quite a prize. As far as I'm concerned, software development is about as much a branch of engineering as actuarial work - yeah, we both tend to study a lot of math, but that's about it. Software "engineering" is a useful metaphor, but I don't want formal, PE style accreditation bodies to start thinking they have any sort of claim on software.
Eliezer 17y ago
> a $1m project with expected value of $1.1m vs $1m project with expected value of $50m Expected utility fail. Dollars are fungible; it is exactly equally important to save money on both projects, but on the second project, we are much more concerned with percentage losses of expected output value as a function of cost-saving attempts.
- billswift 17y ago
  His point was to choose projects more worth doing, that is with a higher expected return, INSTEAD of trying to pinch pennies to get a return from a less useful/valuable product. Or at least that's the way I read that section.
  - bsaunder 17y ago
    "To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?" I was really hoping for more insights to this in the second half, but they never came.
drawkbox 17y ago
This is still the victory of iterative and agile over waterfall. Big up front designs are really only needed when building the shuttle or where people might die. There is no physical installation. The cost of going more than agile or iterative is too risky. Software engineering is also agile and iterative. The nature of the project determines the level of metrics and engineering of maintenance you need. That being said, standards have led us to where we are now with the web. MIME, HTTP, TCP/IP, HTML, etc. The IETF, W3C and other organizations are still engineering standards.
dws 17y ago
Tom DeMarco was part of the paradigm shift toward thinking about software development as an Engineering discipline. He was very influential in his day, and "The Mythical Man Month", with he co-authored with Tim Lister, continues to influence. What's remarkable about his article is that thought leaders of a revolution often go to their graves convinced that they were right. Seeing one thoughtfully recant is a rare pleasure.
- jamesbritt 17y ago
  " ... and "The Mythical Man Month", with he co-authored with Tim Lister, continues to influence." Fred Brooks wrote that book. Perhaps you meant Peopleware?
  - dws 17y ago
    Yup, Peopleware. That's what I get for ignoring the "time for sleep" clue.

69 points by swombat 17y ago

The critical flaw of the Systems Development Life Cycle has always been that you needed to define your outcome before you started development. It was inevitable that modern tools and technologies would turn that process around, that development itself would be used to determine requirements. So now, when you start development (according to the old rules) you already have lots of work done. Does this mean the software engineering is dead? Hardly. It's just evolved to what always worked.

swombat 17y ago

Excellent article, very well put imho. It's interesting to also look at this as an argument for more modern, rails-like dynamic frameworks that enable the transformative result rather than trying to control programmers.

mingyeow 17y ago

What an AWESOME posting. Cannot upvote this enough. Balancing focus and diversification in portfolio is definitely the key to success. Rock on!

DanielStraight 17y ago

I love this quote: "I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product."

stonemetal 17y ago

Project management != Software engineering As a truism Software Engineering is the act of engineering software. Managing the project that is supposed to engineer that software isn't Software Engineering. As long as we are building software larger than a page or two long SE will be important.

marksutherland 17y ago

The majority of this article tackles the over-reliance on software metrics, an issue that many people have brought into question over the last decade or so, and he does a good job of summarising the problem with it. However, in the last two paragraphs he attempts to tar the rest of the Software Engineering discipline with the same brush, painting it as a set of overtly rigid tools bureaucratic managment might use to crush the life out of any software project. I've studied as a computer scientist and as an engineer (electronics) and it's been my constant impression that those trained in the former completely misunderstand the latter. The engineering mindset is one of creative problem solving, using heuristics, tools and systems that have worked well in the past to guide you to your eventual goal, and ignoring them if they don't make sense or will misguide you. Instead many programmers seem to want to find the general algorithm for development. It doesn't exist and in a way its our philosophers stone, it's pursuit wastes time, effort and money. Instead we should be happy with the ever expanding toolkit of techniques the modern developer has at their beck and call whenever they're necessary. That's the real essence of Software Engineering, even if some parts of the industry have gotten lost over the past few decades. Frankly, this article's title is blatant troll-bait and I really should know better.

smithjchris 17y ago
It's by the IEEE. Most of these "elitist clubs" tend to knock out this drivel by the truck load to try and make their members feel relevant and manipulate the industry. Open Group, IEE (UK version of IEEE) are just the same. Fortunately, people just aren't interested any more.
- ben_straub 17y ago
  It's by Tom DeMarco. The co-author of this: http://www.amazon.com/dp/0932633439 http://www.amazon.com/dp/0932633439
- deleted 17y ago
  [deleted]
- Kaizyn 17y ago
  If that's a majority view, then the dumbing down of the discipline is complete.

wglb 17y ago

This is an excellent article. I am not familiar in detail with DeMarco's work, but it is very refreshing to hear a pundit/consultant/authority say "I am uncomfortable with what I said before" after having learned from experience or history. He offers an excellent example of project characterization: "a $1m project with expected value of $1.1m vs $1m project with expected value of $50m".

silentbicycle 17y ago
DeMarco and Lister's _Peopleware_ is excellent, IMHO.

raphar 17y ago

One problem with Software Engineering lies in the engineers themselves when they forget the time or money aspect of their designs. Your design may be perfect for the domain, but if the time you have is just 6 months, you have change your design to something 'buildable' in that time. I fall for this one when I got an interesting/challenging project. Given enough time, the ability of a S.Engineer to find diferent solutions depending on money/time availability will positively affect her/his pay. (and the size of the assignments)

prodigal_erik 17y ago
"A programmer is someone who, given ten days to complete a task, will spend nine days figuring out how to do it in one day."

forgotmypasswd 17y ago

Lol. I just realized that the [scribd] tag was a separate link, and not a warning that the entire link was to scribd. I guess not everyone hates scribd as much as me.

nkurz 17y ago
I've had the same experience, and had been avoiding such links as well. Regarding your 'hate', though, it may be worth noting that Scribd is a Ycombinator company.
- Zak 17y ago
  Are you suggesting that people should not express dislike of YC-funded companies here? I don't think we really want to encourage the creation of taboos like than here.
  - nkurz 17y ago
    No, I was suggesting the presence of links to Scribd may not be intended solely a convenience to the current HN audience. I do think there is some self-suppression occurring regarding YC companies, though. This is a good thing if it encourages more thought as to phrasing, and a bad thing if it creates a taboo.

gruseom 17y ago

Pedantic comments about usage of the word "engineering" are missing the point of this article. What's important is a guy who has been an industry leader for decades reflecting on what he, and the industry as a whole, got fundamentally wrong about making software. That's pretty relevant to anyone who wants to learn from previous experience. (Not everyone does, of course. A lot of software people appear to believe that the past, by virtue of the fact that it didn't contain them, is inherently stupider than the present.)

deleted 17y ago

[deleted]

geebee 17y ago

I'm of the camp that never wants to see the word "software" associated with the word "engineering." They're too different to be under the same umbrella, and I'm worried that the various engineering accreditation bodies will start to believe that software falls under their auspices, like civil or mechanical engineering. It would be quite a prize. As far as I'm concerned, software development is about as much a branch of engineering as actuarial work - yeah, we both tend to study a lot of math, but that's about it. Software "engineering" is a useful metaphor, but I don't want formal, PE style accreditation bodies to start thinking they have any sort of claim on software.

Eliezer 17y ago

> a $1m project with expected value of $1.1m vs $1m project with expected value of $50m Expected utility fail. Dollars are fungible; it is exactly equally important to save money on both projects, but on the second project, we are much more concerned with percentage losses of expected output value as a function of cost-saving attempts.

billswift 17y ago
His point was to choose projects more worth doing, that is with a higher expected return, INSTEAD of trying to pinch pennies to get a return from a less useful/valuable product. Or at least that's the way I read that section.
- bsaunder 17y ago
  "To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?" I was really hoping for more insights to this in the second half, but they never came.

drawkbox 17y ago

This is still the victory of iterative and agile over waterfall. Big up front designs are really only needed when building the shuttle or where people might die. There is no physical installation. The cost of going more than agile or iterative is too risky. Software engineering is also agile and iterative. The nature of the project determines the level of metrics and engineering of maintenance you need. That being said, standards have led us to where we are now with the web. MIME, HTTP, TCP/IP, HTML, etc. The IETF, W3C and other organizations are still engineering standards.

dws 17y ago

Tom DeMarco was part of the paradigm shift toward thinking about software development as an Engineering discipline. He was very influential in his day, and "The Mythical Man Month", with he co-authored with Tim Lister, continues to influence. What's remarkable about his article is that thought leaders of a revolution often go to their graves convinced that they were right. Seeing one thoughtfully recant is a rare pleasure.

jamesbritt 17y ago
" ... and "The Mythical Man Month", with he co-authored with Tim Lister, continues to influence." Fred Brooks wrote that book. Perhaps you meant Peopleware?
- dws 17y ago
  Yup, Peopleware. That's what I get for ignoring the "time for sleep" clue.