Excellent post, this is something that’s been on my mind ever since I took my first programming class. It might be the professors, but a course designed to introduce people to programming feels out of place in a university. Especially when the instructor tells you to launch VS 2008, check w/e boxes, type, and press the compile button.
If this is a craft, where is the guild?
If you go towards crafting instead of engineering, it just means that you have not achieved even the crafting level. But sure as the sun shines, after crafting comes engineering.
I think this man might have been a brilliant developer at some stage, but forgot that the world revolves around people with individual needs. The second fact that he is missing is that with all the new knowledge coming into being a new breed of developer with a much higher understanding of the problem, ie: how to test for drugs with sophisticated algorithms involving various technologies cannot be handled with a standard piece of code.
He is trying to reduce the cost of development to reasonable proportions again. If one looks at the sort of income stream that Microsoft will be collecting for W7 I do understand his concern.
nice article thanks for sharing, wish you continued success
post thank you for the beautiful share with us, respect
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.
@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.
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.
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 
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.
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.
"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”?
“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.
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.
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.
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.
Keanu Reeves and Tom DeMarco quoted in the same article. Whoa.
1 Like
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”.
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.