A New Software Engineering • Hacker News Board

Re: A New Software Engineering

#91

Post by jrochkind1 » Mon, Dec 01, 2014, 9:59 PM UTC

warcher wrote: post #90

jrochkind1 wrote: post #73

Earlier quoted context omitted.

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…

Given the costs involved in making for real high reliability software (think planes, pacemakers, Mars rovers), profits don't factor into it at all-- we're looking at 10x the costs at a minimum. Nobody pays for that level of reliability without an excellent reason.

I'm not talking about making all software as reliable as is needed for planes, pacemakers, etc.

I'm talking about making all software as reliable and secure as appropriate for it's context. I think there's a general opinion amongst many (esp software engineers), that most currently deployed software is not as high quality as it should be, thus the concern on "What are we doing wrong, do we not know how to make quality software?"

Of course, the context and the consensus expectations for reliability/security can change, which is part of what's happened, as software has become more integral to the society and economy.

Re: A New Software Engineering

#92

Post by warcher » Mon, Dec 01, 2014, 10:51 PM UTC

jrochkind1 wrote: post #91

warcher wrote: post #90

Earlier quoted context omitted.

Given the costs involved in making for real high reliability software (think planes, pacemakers, Mars rovers), profits don't factor into it at all-- we're looking at 10x the costs at a minimum. Nobody pays for that level of reliability without an excellent reason.

I'm not talking about making all software as reliable as is needed for planes, pacemakers, etc. I'm talking about making all software as reliable and secure as appropriate for it's context. I think there's a general opinion amongst many (esp software engineers), that most currently deployed software is not as high quality as it should be, thus the concern on "What are we doing wrong, do we not know how to make qualit…

Well, I think I mostly agree. The only distinction I would draw is "good enough for its context" is synonymous in my mind for "as good as I'm willing to pay for." Everybody wants to pay for hamburger and eat caviar, but that ain't how the world works.

For all the increased whinging about software reliability, I have not seen a corresponding increase in what people are willing to pay for software. This indicates to me that we've achieved a level of rough market equilibrium.

But I would be thrilled to be wrong about that. I have a whole laundry list of refactors I'd love to take on. Cleaning up after myself is a luxury I am ill afforded.

Re: A New Software Engineering

#93

Post by tk42 » Tue, Dec 02, 2014, 8:07 AM UTC

My software engineering process works as follows:

I try to code as much as possible as early as possible. I throw away lots of stuff and recode it. Besides that I have an eye for stuff that is "similar" and can be abstracted. If someone wants an estimate, I guess as good as possible.

Big code is idealy split into one-person-chunks each with a documented API, but sometimes many people have to work on the same "files". Then big code is split between multiple people that sit nearby and communicate personally while discussing implementations based on technical arguments.

How to make a product of software is a different story. But I guess it works when you design your product in estimateable pieces and adapt fast to changing requirements.

Also I am pretty sure I forgot one or two things...

Re: A New Software Engineering

#94

Post by garfij » Tue, Dec 02, 2014, 1:52 PM UTC

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…

My impression has been that the people in the LISP community would be happy to tell you about how their model has been fairly consistent over the past several decades and that a lot of the 'new advancements' we're seeing all the time have been available in LISP for that whole time. And, funnily enough, one of the most highly recommended projects in LISP is making your own!

I don't get to deal with LISP anywhere enough to substantiate these claims from actual experience, but that is the impression I have gotten from hanging around places like this.