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

91–100 of 174 posts

Re: Software engineering research is a train wreck

#91

Post by svachalek »

ftio wrote: post #45
shusson wrote: post #37

Earlier quoted context omitted.

> Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process. Do you think software engineering will remain a creative endeavour in the future? We've only been programming in high level languages for 60-70 years. All the while Moore's law has been in effect.

Oof. I have no idea. But since it'll be fun to guess: Absent some kind of magical (from today's POV) AGI, I think I'd probably say yes, but I'm not sure that means software engineering will continue to look the way it does today, at least not universally. My expectation is a pretty linear extrapolation of history. I think new tools and higher levels of abstraction will emerge that will make certain types of tasks unn…

That's what tools like Visual Basic and Delphi were meant to do, and actually were pretty good at for their time. As far as I can tell, we still haven't nearly caught up to the browser/cloud equivalent of these tools.

Things need to sit still for a while longer I guess, but I think there's also some industry changes to blame. In the 90s there was big money in making tools and components for software engineers, while nowadays everyone just uses the best free thing they can find. Granted the free things are way better than they were in the 90s, but I think they're largely killing the market for better things that cost money.

Re: Software engineering research is a train wreck

#92

Post by hwayne »

MiscIdeaMaker99 wrote: post #81
lazyant wrote: post #18

I don't know what "FM" and other initializations are. Please when writing an article, expand them in parenthesis the first time they are mentioned.

I didn't catch that either. Sucks you're getting downvoted for it when it isn't as obvious as others seem to think.

I'll put a quick link in

Re: Software engineering research is a train wreck

#93

Post by pmarreck »

ftio wrote: post #32

I worked on engineering productivity research and measurement at Google for two years until about a month ago. (Opinions my own.) Compared to my former colleagues, I'm an infant in this area, so take this with a heaping of salt. In general, I think the author's cynicism about productivity research is justified, but I think it could have been directed more productively. (NB: the following comments say nothing about ar…

I can prove that languages may differ in productivity (without regards to other variables like the ones you mention) with a simple "proof by extremes": No one would likely dispute the fact that it will be more productive overall to code in Javascript than in Brainfuck (although perhaps not by much).

Re: Software engineering research is a train wreck

#94

Post by sly010 »

lolinder wrote: post #38
star-trek-fleet wrote: post #26

Earlier quoted context omitted.

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 ho…

> 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. This sounds like people do care about screws. You identify two specific failure modes: they could be machined incorrectly, or they could be torqued incorrectly during installation. In either case, it is entir…

Have you heard about jesus nuts? [0]

[0] https://en.wikipedia.org/wiki/Jesus_nut

Re: Software engineering research is a train wreck

#95

Post by mcguire »

"Here’s the only technique I’ve found that works, which I call scrobbling even though that means something totally different:

"1. Search seed terms you know, like “cost of bugs”, in an appropriate journal (here’s one).

"2. Find papers that look kinda relevant, skim their abstracts and conclusions.

"3. Make a list of all the papers that either cite or are cited by these papers and repeat.

"4. Find more useful terms and repeat."

Congratulations! You're a grad student now!

P.S. When I graduated, I had a filing cabinet with two drawers full of papers that felt important enough to save printed copies, from just this process. A couple of months ago, I carted them out to the burn pile, threw them on the pile of leaves and brush, and held a Viking funeral. And I didn't even feel bad. :-)

Re: Software engineering research is a train wreck

#96

Post by hwayne »

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.

Purely from an industrial perspective, interest in formal methods tends to split two ways:

1. Verifying really nasty algorithms, the kind you see in cryptography and embedded systems and stuff where the bugs are triggered by horrific race conditions or incredibly specific malicious inputs that even experts won't think of testing

2. High level specifications of requirements and abstract machines and stuff, where the spec is like 100 lines and the implementation is 10k and you'd prefer to catch some design bugs before you're ten sprints into coding

A lot of bugs in (1) end up being memory-related, which is why you're seeing languages with borrow checking as part of the semantics (Rust). A lot of hype these days is in (2) because it's a lot cheaper and easier to learn, at the cost of having a lower power ceiling.

Re: Software engineering research is a train wreck

#97

Post by twobitshifter »

Quanttek wrote: post #82

> The average developer thinks empirical software engineering is a waste of time. How can you possibly study something as complex as software engineering?! You’ve got different languages and projects and teams and experience levels and problem domains and constraints and timelines and everything else. Why should they believe your giant incoherent mess of sadness over their personal experience or their favorite speake…

I think the issue is that management is not done scientifically. You can see this with something as estimating for a project. Higher ups just ask “how many hours and when can you get it done” - they don’t want you to go through past similar work review it’s timeliness and hours, divide it into smaller tasks, build a project schedule, review productivity trends and resource loadings, or any scientific way of arriving at the number. What they really want is a seat of the pants WAG, which isn’t too big to scare the client, that they can use to get going, with the understanding that shit happens along the way.

Re: Software engineering research is a train wreck

#98

Post by hwayne »

mcguire wrote: post #95

" Here’s the only technique I’ve found that works, which I call scrobbling even though that means something totally different: " 1. Search seed terms you know, like “cost of bugs”, in an appropriate journal (here’s one). " 2. Find papers that look kinda relevant, skim their abstracts and conclusions. " 3. Make a list of all the papers that either cite or are cited by these papers and repeat. " 4. Find more useful ter…

I got into software specifically because I didn't want to go to physics grad school, and now I read more papers than I ever did in physics. Man plans, God laughs.

Re: Software engineering research is a train wreck

#99

Post by twobitshifter »

krisoft wrote: post #83
eschneider wrote: post #55

Earlier quoted context omitted.

It "feels right" and is therefore "truthy."

Do you guys doubt that it is right? What kind of information would you require to show you that it is true? I'm one of the lucky ones who tends to work on safety critical "complex cyber-physical systems". Is that maybe the difference? There is the case where a developer runs unit tests before a commit. Some of the tests are unhappy. Developer fixes it and commits it up. Maybe hours spent? Then there is the case where…

I think that’s the point - the chart confirm your bias and everyone else’s so we accept the results at face value. Nobody really knows if those bar heights were ever measured but of the millions of people to see that chart few questioned it.
Post reply on HN