101–110 of 174 posts
The Head of software side at the BSI commented that tat for old timers in QA - software was odd as they "did not know wear to hang the defect tags"
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…
> Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process Exactly. And it's less like movie production and more like 4,000 people trying to collaborate to produce a million-page novel. It does bear some resemblance to design and engineering, but with custom materials and components that have never been used before and need to be created specifically for the proje…
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 ho…
This just isn't true. Off the top list:
- are they the right spec for the load
- are they the correct material and finish for environment
- do they have the right head (for manufacture, but also support, etc.)
- what vendor options do we have (the more unusual, the more this gets interesting) and what risk
- are the manufacturing SOPs correct for this
- are the manufacturing SOPs being followed
- etc.
And that's the simple things like screws. You may not care about any of this stuff until it fails; but if nobody cares, things will fail.
The real difference between stuff like this an software engineering is that in far more cases for hardware an engineer can look up the correct solution and use it. You still have to care enough to check that, and check it against any change, etc.
Bold claim. Any data at all to back that up?
My guess based on experience would be most developers are unfamiliar with the term and haven’t made a judgement one way or the other.
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 ho…
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,…
Aren't we more or less doing that at the language level? C had lots of memory bugs, so C++ tried to fix it with collections, iterators, and smart pointers. It was still hard, so Java came along with GC and null ref exceptions. The situation was less bad, but multithreading became popular and Java didn't help as much as we would like so the Rust people gave it a go.
Though I really do suggest trying it yourself. If you want to be a better programmer, developing a style that minimizes bugs you write is pretty much pure win.
Earlier quoted context omitted.
Depends. You could then run experiments on team performance in the requirements-to-code phase, separate from the generating-requirements phase. That has its place. And then you could experiment with teams trying to convert informal requirements to formal requirements. That might let you learn some things about the parts that you couldn't learn if you dealt with the whole.
Those are not separate phases, they take place simultaneously. No one does waterfall development anymore.
" 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…
Search engines for papers suck, bad. At the fringes of human knowledge, you need an actual brain to process cutting-edge research. Either your own non-expert brain, or an expert brain to help guide you.
That process is the same in every field. Older fields have textbooks with knowledge distilled from experts. That's a good place to start to get the state of the art > 20 years ago.
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…
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.
Its he same wisdom, but communicated in a more direct way.
Earlier quoted context omitted.
> It got me comparing precision machine design to software engineering. I think the problem is that the failure of physical systems are often caused by random failures, which can be tested for and probabilities determined e.g how long before a bolt breaks. This as opposed to software, which most often fail due to systematic errors and cannot be tested completely.
In precision machine design the failures are typically not statistical (like in fatigue failures) but due to errors of design. E.g. the tool spindle can maintain the desired tolerance when running from a cold start but after several minutes thermal effects cause it to be out of tolerance.