Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A New Software Engineering

queue.acm.org

Post reply on HN
Print view View original

21–30 of 94 posts

Re: A New Software Engineering

#21

Post by cageface »

Only when we can specify the design of a software product with the same precision that we can specify the design of a skyscraper will we ever see the failure rates of software "engineering" efforts approach those of other engineering fields. As any practicing programmer can tell you, even the best upfront design specs are imprecise and incomplete. And most of the time those specs are changed over and over again during the development effort so radically that the final product is often barely recognizable.

I put the blame for this firmly on the shoulders of the "clients". We can and do achieve high success rates with low defect counts in special cases where the goal is precisely and clearly defined and the development budget is sufficient. When we start caring about the quality of a website or mobile app as much as we care about the quality of the software that runs airline flight control systems or medical devices then we'll see real software "engineering" emerge.

Re: A New Software Engineering

#22

Post by 31reasons »

thibauts wrote: post #10

Another silver bullet in the making. I don't mean to be rude but to me it's pure BS. A grand plan, a conclusion talking about paradigm shifts, and no substance at all. Seeing the method co-signed by Robert Martin even made me chuckle a little. I guess we're on for a second round. This is clearly meant for management (again) and doesn't give a hint of a clue to what is the practice of software engineering. Won't they…

Software Engineering is in a way meta engineering discipline. Problem domains are vastly different. A mobile game development is different than building a system software for surgical robot. The first step is to define the vocabulary of the solution space and then build the solution based on that vocabulary. Expectations of reliability, maintenance, requirement changes adds another dimension to its solution space.

Re: A New Software Engineering

#23

Post by sedachv »

jacques_chester wrote: post #18
seanmcdirmid wrote: post #7

Earlier quoted context omitted.

What is the equivalent in other fields that build things? I mean, project management must be studied in other disciplines, and what have they come up with?

A book I read, Industrial Megaprojects , suggests that everyone else makes a lot of the same dumb mistakes we do. We're not comparing ourselves to civil, structural, process, mining, aeronautical or industrial engineering. We're comparing ourselves to flawless platonic ideals of those professions that we invented whilst talking amongst ourselves.

Thank you! I wish more people would go and learn what engineering is in other fields before trying to discuss software engineering. I recently had an argument on HN about the particulars of this topic: https://news.ycombinator.com/item?id=8633616

Another book I can recommend on the subject is Petroski's To Engineer is Human.

Re: A New Software Engineering

#24

Post by jacques_chester »

sedachv wrote: post #23
jacques_chester wrote: post #18

Earlier quoted context omitted.

A book I read, Industrial Megaprojects , suggests that everyone else makes a lot of the same dumb mistakes we do. We're not comparing ourselves to civil, structural, process, mining, aeronautical or industrial engineering. We're comparing ourselves to flawless platonic ideals of those professions that we invented whilst talking amongst ourselves.

Thank you! I wish more people would go and learn what engineering is in other fields before trying to discuss software engineering. I recently had an argument on HN about the particulars of this topic: https://news.ycombinator.com/item?id=8633616 Another book I can recommend on the subject is Petroski's To Engineer is Human .

A good book, definitely. I reviewed it here:

http://chester.id.au/2013/07/07/review-to-engineer-is-human-...

Re: A New Software Engineering

#25

Post by scribu »

seanmcdirmid wrote: post #19
scribu wrote: post #9

Earlier quoted context omitted.

The article points out in the beginning that borrowing project management practices from other disciplines is what we tried to do (which gave us The Waterfall method) and it doesn't work. That said, I agree with the GP in that I was expecting more focus on actual software matters, like how to test the reliability of a system before it's built etc.

I don't think waterfall is actually used in other disciplines, perhaps we were just cargo culting back then? But my question is: if SE is supposed to be based on a theory of project management, then what is the theory used in other disciplines? Or do project management not see that as their underlying theory, but rather something more hard like physics or chemistry? It sounds like there must be a general field of pro…

> I don't think waterfall is actually used in other disciplines

From http://en.wikipedia.org/wiki/Waterfall_model:

"The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development."

> It sounds like there must be a general field of project management out there

Yes, project management is a discipline in itself. Why the article is calling its project management framework for software development "software engineering" is not clear. Probably because it sounds more promising; it promises to be the silver bullet:

http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

Re: A New Software Engineering

#26

Post by brudgers »

discreteevent wrote: post #8

Software is more a design activity than an engineering activity. In the construction world it would be more like architecture than civil engineering. Architecture in the sense that you do need technical knowledge but it's much more about thinking about how do we design a building for people who are engaged in certain activities. What are their needs. How does it fit in with its environment etc. Soft things. Burt diff…

In the US and many other parts of the world architects are professionally liable for the public welfare in general and life safety, regulatory compliance and system performance specifically of the buildings they design.

The practice is regulated in these places because there is very little soft about people dying. It is the absense of a culture that comes from individuals aaccepting such responsibility that concerns people like the author and Uncle Bob.

Re: A New Software Engineering

#28

Post by foobarian »

jacques_chester wrote: post #17

Computer science isn't a science and it's not about actual computers. Software engineering isn't engineering and is really about the limits of people, not software in and of itself. Nevertheless, my job title is "Software Engineer". Where it makes sense, I model myself after our elder cousin professions. When it doesn't, I don't.

I have that title too; I feel that basically "coder" + "process" = "software engineer."

Re: A New Software Engineering

#29

Post by coldtea »

taeric wrote: post #6
sgrove wrote: post #5

Earlier quoted context omitted.

But the assertion is that bridges could be built today using techniques from the 1950's, and they would still be good bridges, because the principles and physical laws they were built on haven't changed. Software design had a lot of cool things happening in the 1980's (possibly more in the 1970's, though), but the mindset has shifted since then. How many people are implementing their own VM's? How many are running on…

And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion. I don't know what to say regarding your examples. Don't put too much credit in JIT and whole-program optimizations. One could just as easily point to the fact that what used to be too slow of a program is now fast enough wi…

>And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion.

I find that they (from the '50s and even older) hold up just fine.

If software worked initially, and survived 60 years that well as bridges from the 50s do today, that would be a miracle.

Re: A New Software Engineering

#30

Post by discreteevent »

brudgers wrote: post #26
discreteevent wrote: post #8

Software is more a design activity than an engineering activity. In the construction world it would be more like architecture than civil engineering. Architecture in the sense that you do need technical knowledge but it's much more about thinking about how do we design a building for people who are engaged in certain activities. What are their needs. How does it fit in with its environment etc. Soft things. Burt diff…

In the US and many other parts of the world architects are professionally liable for the public welfare in general and life safety, regulatory compliance and system performance specifically of the buildings they design. The practice is regulated in these places because there is very little soft about people dying. It is the absense of a culture that comes from individuals aaccepting such responsibility that concerns…

I don't mean that all of what we do is soft. I mean about 50℅ of it (in my case anyway, the rest I spend on data structure design, performance, testing, maintainability etc etc.) I'm saying that it is more like architecture than civil eng. Because it has such a large soft design component it will always elude a hard engineering approach.
Post reply on HN