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

61–70 of 94 posts

Re: A New Software Engineering

#61

Post by hueving »

taeric wrote: post #49
coldtea wrote: post #29

Earlier quoted context omitted.

> 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.

This leads to a few questions, though. First, if bridges were built just fine in the 50s, why do they build them differently nowdays? Second, why is the maintenance cost of bridges decidedly non-trivial? Third, is there any software that is that old that still works fine? For the first question, I would only be offering speculation. Google and friends can give pretty good references. For the second, a quick google gi…

Tex is not 50 years old. Also, it's borderline unusable to anyone who hasn't mastered what "underfilled hbox" means and the like. Internally it's so unsustainable that people are trying to start from scratch with full rewrites. However, because there actually isn't a standard for latex beyond "how tex" renders it, it's a horrific undertaking. TeX is far from "just working".

Onto bridges, just because they build them differently now does not negate the fact that 50 year old bridges are still reliable and safe to drive over because they were engineered well. Their shortcomings and failure modes are well known so maintenance can be performed to prevent collapses.

50 year old bridges may be expensive to maintain at this point, but the fact that it's still possible shows that they were engineered well. They may build them differently today, but that's more likely related to cost constraints changing (e.g. can't afford an army of riviters now) rather than the engineering being unsound.

Re: A New Software Engineering

#62

Post by thibauts »

hueving wrote: post #60
pm90 wrote: post #47

Earlier quoted context omitted.

Engineering is not as simple as building against gravity. There are a lot many things that "engineers" (non-software) have to take account of, even in something as mundane as laying out a road. In this example, you not only have to build the road within the area; you have to build it so that it has the right curvature so that vehicles can make the turn etc. You have to make sure that the road you're laying out has a…

A road is a bad example. The only reason a road is required is because of gravity. I disagree with your hand wave of "software = art". Software is also bound by many constraints. Time (as you mentioned) is not trivial because it's the difference between useless and useful software. Memory also puts limitations in that can't be ignored. Useful software runs on real machines bound by physics. Theoretical computer scien…

Software engineering is an art in that it's more like theory building than theory using. Each project, each context is its own set of new physical laws.

Re: A New Software Engineering

#63

Post by Spearchucker »

I see a lot of detractions here. One of the authors, Ivar Jacobson, is behind UML (together with Grady Booch & James Rumbaugh). Which explains where SEMAT fits - the enterprise. Specifically those that live in a world of class diagrams, sequence diagrams and activity diagrams. I doubt there's much benefit to the typical HN audience (for reasons the comments here point out), but SEMAT has a place.

Re: A New Software Engineering

#64

Post by antimagic »

Animats wrote: post #59

Software engineering was taken more seriously 20 years ago than it is now. There have been some notable successes of rigorous development, but they're not well known. Here are two in wide use. The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for…

"The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, there would be regular cellular blackouts."

That's... an interesting claim. You're basically saying that a cellular network is wide open to DOS attacks. I would need to see some serious proof before accepting such a claim.

Re: A New Software Engineering

#65

Post by fsloth »

coldtea wrote: post #29
taeric wrote: post #6

Earlier quoted context omitted.

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.

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

Given a Fortran compiler I see no reason why lot of the numerical stuff in netlib would not work just as well in 60 years time: http://www.netlib.org

Re: A New Software Engineering

#66

Post by golemotron »

I lost it when I saw requirements as a cornerstone. There are no requirements - it's all design. The word 'requirement' is an artifact from processes where you have handoffs from one group of people to another rather than integrated discovery and coding. When you look at things as requirements you lose the fact that most things are negotiable and should be negotiated in service of the ultimate design.

Beyond that, it's worth noting that when the same people go from idea to A/B testing to full production the idea of a 'requirement' seems quaint.

Re: A New Software Engineering

#67

Post by lucozade »

TL;DR some perennial software methodology consultants have come up with a base class for software methodologies.

It seems suspiciously like it has the usual properties of post-facto defined base classes i.e. arbitrary and fragile. But I could be wrong.

BTW if you found equating physics to marking stakeholder-ness out of 6 hard to swallow, you might struggle with "Major-league SEMAT". It reads a bit like an outline for the next Scott Adams book.

Re: A New Software Engineering

#68

Post by spacecowboy_lon »

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…

Are they? I worked for a top 5 consultanting enginers and the buck stoped with us in ters of the desugn all the archtects did was make it look purty.

Re: A New Software Engineering

#69

Post by lukesan »

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…

>What we really do is assess the validity and feasibility of what an user wants

Then why do software developers get no training in talking to users? In understanding them and make sense of what they tell us and what they really?

This to me is the biggest short coming of today's software 'engineering'

Re: A New Software Engineering

#70

Post by thibauts »

antimagic wrote: post #64
Animats wrote: post #59

Software engineering was taken more seriously 20 years ago than it is now. There have been some notable successes of rigorous development, but they're not well known. Here are two in wide use. The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for…

"The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, th…

Any wireless link is open to DOS attacks: jamming.
Post reply on HN