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

Software engineering research is a train wreck

buttondown.email

Post reply on HN
Print view View original

21–30 of 174 posts

Re: Software engineering research is a train wreck

#21

Post by MengerSponge »

Sci-hub is great, but it should be your last resort. University librarians have explained this to me, but it has to do with how Sci-hub counts towards access counts of obscure journals.

Unpaywall provides an excellent browser extension. https://unpaywall.org/

If you have time, you can request a copy of a paper directly from the corresponding author. We love for people to be interested in our work, and we would rather you put that $40 access fee towards something that benefits society.

Re: Software engineering research is a train wreck

#22

Post by [deleted] »

jeffreyrogers wrote: post #12

I was reading this thesis the other day[0], which is on precision machine design. It got me comparing precision machine design to software engineering. A big part of why we're able to design extremely precise machines (the author worked on a lathe used for machining optical parts for the National Ignition Facility) is because we can characterize exactly where errors will come from (e.g. structure isn't rigid enough,…

[deleted]

Re: Software engineering research is a train wreck

#23

Post by ska »

jeffreyrogers wrote: post #12

I was reading this thesis the other day[0], which is on precision machine design. It got me comparing precision machine design to software engineering. A big part of why we're able to design extremely precise machines (the author worked on a lathe used for machining optical parts for the National Ignition Facility) is because we can characterize exactly where errors will come from (e.g. structure isn't rigid enough,…

> while no large team (that I'm aware of) has done anything similar.

In areas like avionics, medical devices etc., there are formal production engineering methods applied to software as a matter of course. It can very work well, but it is definitely expensive compared to industry average.

Re: Software engineering research is a train wreck

#25

Post by arkitaip »

MengerSponge wrote: post #21

Sci-hub is great, but it should be your last resort. University librarians have explained this to me, but it has to do with how Sci-hub counts towards access counts of obscure journals. Unpaywall provides an excellent browser extension. https://unpaywall.org/ If you have time, you can request a copy of a paper directly from the corresponding author. We love for people to be interested in our work, and we would rather…

Amazing extension. Thank you.

Re: Software engineering research is a train wreck

#26

Post by star-trek-fleet »

jeffreyrogers wrote: post #12

I was reading this thesis the other day[0], which is on precision machine design. It got me comparing precision machine design to software engineering. A big part of why we're able to design extremely precise machines (the author worked on a lathe used for machining optical parts for the National Ignition Facility) is because we can characterize exactly where errors will come from (e.g. structure isn't rigid enough,…

I happened to also delved into machining tools and work as SWE full time.

This comparison to me, is not workable between machine building and software.

So the difference is that machines do simple things and not changing. But software do complicated things and always changing.

You can easily understand which parts and/or ways of operating that cause machine misbehaving. Because you have full grasp of the parts and how they assembled and work

But you cannot achieve the same for software, as each time it will be a new problem, or a new feature not working as expected.

Actually, if you think a bit more, you might realize that we actually cares very little about the microscopic features of machines. For example, no one cares about screws, as long as they are machined according to spec, and torqued correctly during installation. The chance that a random screw to bring down a whole machine is close to zero.

But any function in a software can bring down the whole software...

Re: Software engineering research is a train wreck

#28

Post by SebastianFish »

NohatCoder wrote: post #17
SebastianFish wrote: post #6

Testing different methods of development in terms of speed, cost and quality is really hard. The most convincing approach to me would be a single blind experiment to hire two software development teams and have them build to the same set of requirements in two different ways. But then it is hard to know whether you are really comparing the method of software development or the quality of the software teams. So two so…

"A specification that can be implemented using formal methods". That is just source code. If the specification can completely define arbitrary programs it is necessarily Turing complete on its own, and as such prone to the same type of bugs as any other program.

I think you are speaking to one of the core tensions in formal methods. The difference between a specification and an implementation can get blurry. Where formal methods get interesting is statically proving properties about the specification. Take a simple example of a sorting algorithm. The two most commonly proved properties of these algorithms are that they 1) return a permutation of the input list (no items removed or duplicated) and 2) that the output of the list follow some sort of ordering.

One way to look at things is to say the permutation and ordering property checkers are the specification and the actual sorting algorithm is the implementation.

To your point about the specifications being Turing complete, some tools will put restrictions on the specifications to make function termination highly likely. COQ for instance requires that recursive functions be "decreasing in their inputs" AKA that subsequent calls to the same function are passed fewer items or elements than the parent.

Re: Software engineering research is a train wreck

#29

Post by moksly »

SebastianFish wrote: post #6

Testing different methods of development in terms of speed, cost and quality is really hard. The most convincing approach to me would be a single blind experiment to hire two software development teams and have them build to the same set of requirements in two different ways. But then it is hard to know whether you are really comparing the method of software development or the quality of the software teams. So two so…

It’s not that hard is it? There recently was a study on the value of testing and best practices linked here on HN, that I of course can’t find now, where the researchers looked a thousands of projects. Over all there was no scientific proof that testing and best practices lead to better results than just making spaghetti without a recipe.

Having worked in an public enterprise organisation that buys a lot of different software for some decades, it sort of fits with our completely anecdotal data. We still prefer suppliers that have all the nice buzzwords, but if you look at our projects there is just no correlation between their methods and how the software project goes through its livecycle. And this is with everything from the old COBOL systems to modern micro service this and that cloud solutions.

For the past five years I’ve had a near little sidejob as an external censor for CS students, and it’s been interesting to follow how their software design metrology changes rather rapidly, without any real scientific reason as to why that is. Mostly it seems like there is an entire field of “education” dedicated to getting people to do software design and project management in the way that sells the most licenses to Atlassian or whatever else, or simply the most books. It’s really very comparable to the self-health industry, where you’ll have answers for everything.

Sure it’s mostly anecdotal, but preaching that test driven development or going Agile SOLID wild turkey is the holy grail is exactly the same as preaching some diet where you get to eat as much you want as long as it isn’t carbs. Sure you can lose weight, but it’s not like it’s the only way to lose weight and next year it’ll be about going on a juice cleansing or something and then something different after that.

Re: Software engineering research is a train wreck

#30

Post by dangerlibrary »

jeffreyrogers wrote: post #12

I was reading this thesis the other day[0], which is on precision machine design. It got me comparing precision machine design to software engineering. A big part of why we're able to design extremely precise machines (the author worked on a lathe used for machining optical parts for the National Ignition Facility) is because we can characterize exactly where errors will come from (e.g. structure isn't rigid enough,…

The FoundationDB team took a different approach, that I found pretty interesting. They created a fully deterministic (single threaded) simulation of a distributed database, and then use that simulation to test their implementation of the database under difference scenarios. They'd probably be interested in something like what you describe, as the bulk of their work seems to be rooting out and squashing bugs caused by factors out of their control (dropped connections, etc.)

https://www.youtube.com/watch?v=4fFDFbi3toc

Post reply on HN