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

71–80 of 94 posts

Re: A New Software Engineering

#71

Post by coldtea »

fsloth wrote: post #65
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.

"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

Libraries sure. I'm talking about production software.

Re: A New Software Engineering

#72

Post by thibauts »

kabdib wrote: post #31

Recipe for making great software: - Build a good team. Keep management overhead and bullshit to a minimum. Motivate people by giving them really good people to work with and not pulling crap compensation games. - Do your product three or four times. Rule of thumb: When you're absolutely sick of re-writing the thing and you're ready to work on something else (probably at about this many repetitions) you're reaching th…

This.

Things go wrong in a team (with or without a particular silver bullet) when there are bad or unmotivated programmers, or when there are no experienced leads to pass the wisdom.

Recruiter more often than not don't realize this is a sure recipe for failure. As studies don't produce software engineers but merely (in the best case) algorithm engineers, and as software engineering is not a thing yet, the only thing we can rely on is the past successes of experienced individuals.

Methodologies won't remove complexity but only provide an additional (time-consuming) component to your complexity average that will make things look a bit better on a cursory glance but won't reduce at all your codebase complexity and maintenance costs.

Try instead to make your team spend half of its time doing simple things totally unrealted to your project or product (like piling cubes all day long) and you'll feel the exact same relief (half better) and have the exact same productivity gain (zero).

Re: A New Software Engineering

#73

Post by jrochkind1 »

warcher wrote: post #37

It's not like we can't design very elegant, robust, reliable software, you know. We just can't find anybody to pay for us to retool the whole stack (and I do mean the whole stack, since we're only as strong as our weakest link) while the current ad hoc solution operates within acceptable parameters. The guy who wrote this paper, in my opinion, is missing two really bedrock principles of "pure" engineering-- manufactu…

I've been increasingly wondering if the cost of building reliable, effective, and secure software in all the places we use it... is just more than we can afford on a social level (like a higher percentage of GDP). With that price mostly being people, of course.

When we say "We don't know how to build good software", does that really just mean "We don't know how to build good software cheaply enough for the businesses that use it to still remain sufficiently profitable"?

I may not have said this quite right, I keep coming back to it and trying to think it through more. It's not a popular thing to say on HN.

Re: A New Software Engineering

#74

Post by hxa7241 »

calinet6 wrote: post #43
31reasons wrote: post #22

Earlier quoted context omitted.

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.

The best way I've heard this described is this: Engineering has a well-defined constant you're always building against: gravity. In software, you choose your gravity, and it changes all the time. Sometimes there are twelve gravities. Sometimes there are different types, and they interact in complex unpredictable ways. In short, it is a much more difficult problem. But personally I believe we can reach a meta-engineer…

Software is not all made up out of thin air -- you do not 'choose your own gravity'. The equivalent of phyical laws in software are computational/algorithmical, logical laws.

For example, sorting cannot be done faster than O(n log n) -- that is as hard and objective as anything physical. (In fact, one would think it is even harder in some sense, since it is so purely logical.). Software is built within algorithmic constraints.

Re: A New Software Engineering

#75

Post by calinet6 »

thibauts wrote: post #62
hueving wrote: post #60

Earlier quoted context omitted.

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.

This is the point, yes.

Re: A New Software Engineering

#76

Post by lucasnemeth »

I HATE WHEN PEOPLE MISUSE THOMAS KUHN. Read the goddam book, or actually read and try to understand it. The scientific revolution occurs in opposition of the normal science period, we never had a normal science period in software development (or engineering, if you like this awful term), so it makes no sense to use Thomas Kuhn here. Which is a very profound and complex author discussing a epistemological paradigm shift, really different from this nonsense there.

Re: A New Software Engineering

#77

Post by fsloth »

coldtea wrote: post #71
fsloth wrote: post #65

Earlier quoted context omitted.

"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

Libraries sure. I'm talking about production software.

Yes, that's an entirely different thing. But I would rather compare a production software system to something bit more dynamic, like a nuclear plant or an airplane than a bridge.

Re: A New Software Engineering

#78

Post by lostcolony »

sgrove wrote: post #5
taeric wrote: post #3

Earlier quoted context omitted.

I think you both a) are greatly unfamiliar with bridge building practices and b) underestimate the ability of 1980s software design. Seriously, were there shortcomings in the software design of yesteryear? Almost certainly. Are they blown vastly out of proportion in most discussions? My assertion is that they are. Sadly, I do not know as that I have anything coherent to offer on how to fix things. What I can offer is…

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…

If software engineering is shifting, it's shifting due to the youth of the discipline.

Remember, we've been building bridges for thousands of years. We've had a lot of time to figure out how best to do it. The amount of improvement we've had in 50 years in terms of technique is probably pretty small; improvement in materials is the more likely reason for any variations in technique.

Re: A New Software Engineering

#80

Post by antimagic »

thibauts wrote: post #70
antimagic wrote: post #64

Earlier quoted context omitted.

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

Jamming is not a DoS attack. The essential feature of a DoS attack is that it forces the receiver to use resources, which it can then not attribute to legitimate users of the service. Jamming does not force a cell tower to use resources, hence it's not a DoS attack.

To put it another way, if jamming is a DoS attack, then so is hacking a server and reconfiguring its DNS. But we don't call that type of attack a DoS attack, we call it a penetration, or simply a hack.

And yes, wireless communications are susceptible to more physical attacks, such as jamming, but jamming is a) easy to track down, and hence dangerous to execute, b) expensive, you need to invest in special hardware to do it and c)surprisingly difficult to effectively execute in a radio environment like a cell network, which is generally quite adept at routing around things like jamming ( if you put your jammer between me and the antenna, my phone will in all likelihood simply find another antenna to connect to on the other side of me - with signal strength dropping as the square of the distance, your jammer is going to need to be BIG to jam me effectively).

Post reply on HN