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

161–170 of 174 posts

Re: Software engineering research is a train wreck

#161

Post by bob1029 »

feoren wrote: post #146
bob1029 wrote: post #138

Software engineering can only exist with an incredible amount of discipline. We routinely start new implementations in excel and perform formal normalization checks over models before writing any code. You can get away without having a strong type system as long as your tables and relations are clean. This stuff is so powerful. Figuring out how to funnel your domain instances into a SQL db and writing all your comple…

Software engineering is so weird -- what you've just described sounds awful to me. I believe almost the exact opposite of everything you've said. Yet I have no doubt* you've seen good results from your approach, and I get good results from mine. It's surprising how personal software engineering really is. * I do actually have doubts, because 99.9% of software is utter garbage. But I'm trying to be more positive and t…

Willingness to tolerate formal methods does not mean you always have to endure pain and suffering.

On the contrary, you may find that you are shipping software that is so good you begin to see the value.

For a lot of shops, the problem domain probably isn't complex enough to justify intense formality in the process (i.e. engineering). Once you are dealing with monsters like supply chain or factory automation, you can't play games anymore.

Re: Software engineering research is a train wreck

#162

Post by AndyMcConachie »

lifeisstillgood wrote: post #79

My two cents: Software is a form of literacy not engineering. One good bridge looks and acts almost exactly like every other bridge in the world. Good software that does a given job can be unrecognisable compared to other good software that does exactly the same job. Software is more like a novel than a bridge. Maybe, maybe we can apply engineering terms to machine code or assembly. But the abstract levels we all wor…

I tend to agree with you as well. I've also come to the conclusion that conceiving of software as some new 'kind' of non-linear writing is more productive than understanding it through the traditional engineering discipline.

But it is both and it is neither. Software is a new thing that we have yet to fully understand.

Re: Software engineering research is a train wreck

#163

Post by dalbasal »

carlosf wrote: post #147
dalbasal wrote: post #140

Earlier quoted context omitted.

>> I do not believe in the possibility of a "General Theory of Productivity." Important frame. I think any effort that doesn't start with this statement is probably headed for frustration. I reckon this is true also for education, aspects of economics and many other fields. Besides sloppy and/or cynical work, I believe a lot of the "replication crisis" relates to this. Do we really expect that a relationship between…

Well written!

cheers.

Re: Software engineering research is a train wreck

#164

Post by goodpoint »

Joeri wrote: post #118

I went into this software engineering productivity research rabbit hole a decade ago and came away similarly depressed with the lack of rigor in our field. What I’ve come to believe: - Software engineering is not an engineering discipline, it is a craft. It may or may not one day become an engineering discipline, I find this impossible to tell. - The difference between a feature and a bug is largely one of semantics,…

> Software engineering is not an engineering discipline, it is a craft

Software engineering is *still not treated* as an engineering discipline, it is *still treated as* a craft

Re: Software engineering research is a train wreck

#165

Post by goodpoint »

rhizome wrote: post #139
jeddy3 wrote: post #75

Earlier quoted context omitted.

I seems like many posters in this thread try to classify software enineering as either creative or "mindless factory-work". Where actual enineering disciplines has the risk of removing the creative part. I think this classification is wrong. There IS NO mindless factory-work. Just as in other enineering disciplines, our work is not manufacturing. It's just that the actual manufacturing does not exist (or rather is do…

At the very least, I imagine a true engineering version of software development would be fundamentally driven by Big-O. Everything justified and implemented in terms of calculable facts. Repeatability might emerge from this. I think of it this way: what would a CRC manual[1] for software engineering comprise? 1. https://en.wikipedia.org/wiki/CRC_Handbook_of_Chemistry_and_...

The problem is that this is only "the very least".

Re: Software engineering research is a train wreck

#166

Post by goodpoint »

ctvo wrote: post #133
Hermitian909 wrote: post #132

Earlier quoted context omitted.

The poor ontology backing the term software engineer has always seemed to me like the primary culprit for this problem. I've often heard people doing any of the following for their day job referred to as software engineers: - people who write basic static sties - people who write wordpress sites - people who write simple CRUD apps - people who write hardware drivers - people who write compilers - people who write dat…

Do you think other engineers think this way? Your bridge is only 20 yards over a creek, you're not a civil engineer? I'm sure the complexity, depth, and expected maintenance of some bridges vary too.

> Do you think other engineers think this way?

Yes, and that's correct. If your skills go as far as building a 1-meter tall wall around a patio you are not an engineer.

Re: Software engineering research is a train wreck

#168

Post by Epa095 »

bob1029 wrote: post #161
feoren wrote: post #146

Earlier quoted context omitted.

Software engineering is so weird -- what you've just described sounds awful to me. I believe almost the exact opposite of everything you've said. Yet I have no doubt* you've seen good results from your approach, and I get good results from mine. It's surprising how personal software engineering really is. * I do actually have doubts, because 99.9% of software is utter garbage. But I'm trying to be more positive and t…

Willingness to tolerate formal methods does not mean you always have to endure pain and suffering. On the contrary, you may find that you are shipping software that is so good you begin to see the value. For a lot of shops, the problem domain probably isn't complex enough to justify intense formality in the process (i.e. engineering). Once you are dealing with monsters like supply chain or factory automation, you can…

> On the contrary, you may find that you are shipping software that is so good you begin to see the value.

You may also find that when you finally do ship, everyone had started using your competitor, or that your customers needed something slightly different, or that the cost of waiting for you was so high it would have been better having something early.

I have great respect for formal verified software, I have even touched on it a bit during my PhD, and there are definitely places for where it makes sense. Same for formal methods in general. But there are other software tasks where it is not just 'not needed' but it is actually the wrong choice. It depends a lot on the opportunity cost of delivering later, and on how well defined the tasks are, and how preffesional the customer is. And the tasks where less formal methods are the right way are not "playing games", they are solving the problem under a different set of constrains, also doing software engineering.

Re: Software engineering research is a train wreck

#169

Post by krisoft »

gilbetron wrote: post #136
krisoft wrote: post #83

Earlier quoted context omitted.

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…

Imagine a requirements document for Hacker News - such documents traditionally have a tremendous amount of change control around it, with tons of review for every change. Remember, people like you believe it is 100x easier to catch a bug in requirements and 100x gives you lots of budget to spend to make sure you catch bugs in requirements. So, there's a bug in the requirements document. Specifically, the 'logout' lin…

Is this an imaginary situation or a real world experience of yours? I don't deny that IT is a wide and varied place, everything is possible I guess.

In my experience in situations where changing a typo in a document was hard, changing the production code was even harder. But happy to hear your story where this wasn't the case.

> Remember, people like you believe it is 100x easier to catch a bug in requirements

What? I never said that. It is easier to fix, if the problem is caught. That says nothing about how easy or hard it is to catch it.

> Trivial example, but there it is.

The original question was "Are Late-Stage Bugs More Expensive?" To which my answer was "Yes, but I can't show you my proof because I work on proprietary projects" (which I understand is an answer which leaves everyone unsatisfied.)

Your counter argument is "But let's imagine it is not!" ... which is what the phrase "begging the question" originally used to refer to. Imagining that the answer to a question is not what my experience tells me is not a convincing argument. But maybe I misunderstood what you wrote. If I did I'm sorry about that.

Re: Software engineering research is a train wreck

#170

Post by true_religion »

smnrchrds wrote: post #151
ctvo wrote: post #133

Earlier quoted context omitted.

Do you think other engineers think this way? Your bridge is only 20 yards over a creek, you're not a civil engineer? I'm sure the complexity, depth, and expected maintenance of some bridges vary too.

In my field (mechanical), there are engineers, technicians, and drafters. Each of the above require more education than the next, and is paid better than the next. Someone who only does drafting work will not describe their job as engineering, nor are companies likely to ask engineers to do drafting because it doesn't make sense to pay someone an engineer's salary for that kind of work. Basic static site seems like d…

In a way, software development is more like writing than it is engineering.

There is a continuum between people who author crud apps and people who author compilers, but you can go from one to the other simply by having industry experience and access to good books.

Post reply on HN