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.
I think its Software Engineering as a movement, especially in the 90s, that has completely misunderstood engineering. While engineering may have a lot to offer the making software, the movement that is (or perhaps was) Software Engineering did try make a set of overtly rigid management tools.
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.
I won't mod you down, because I think your view needs to be out there. But read the article - it hardly seems like paean to any doctrine. Rather, it seems like an insightful look back on a long career.
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.)
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".
"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."
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.
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.
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)
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.
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.
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.
> 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.
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.
"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.
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.
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.
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.
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.
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.
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.