81–90 of 174 posts
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.
This argument could be used for literally any science but, for some reason, it seems to fall on attentive ears mostly in the software industry.
> ...“bugs found in requirements are 100x cheaper than bugs found in implementations.” ... There’s one tiny problem with the IBM Systems Sciences Institute study: it doesn’t exist It's funny to think how much of an effect this chart had on software engineering as a whole. I remember learning it at university and until today I thought it had some basis in science.
It "feels right" and is therefore "truthy."
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 something goes funky in the real-world all-up integrated system at the test range. Even in the best case tens of people waste a day. If we are unlucky it is a hard one and a small army of the most senior developers with the best operators and hardware people are hunting the bug for weeks. I fear to even sum op the wasted cumulative work days.
I lived through multiple of these at different companies on different projects. (Both the first kind and the second kind.)
Is the question if this is true? Or maybe the question is if this is true for your area of the industry too?
Obviously I won't be able to provide sources for the ones I worked on. I bet no company really would want to release the hard data on these things. So let's look at some well-publicised problem caught in production: The Boeing 737 MAX MCAS issue. 346 deaths, 1 year, 8 months and 5 days grounding and the estimated direct costs are US$20 billion.
Obviously this is all super anecdotal. I just want to understand what part of the question/problem you have doubts about.
Greg Wilson is more positive. Though he does agree that nobody cares. https://third-bit.com/2021/07/17/software-engineerings-great...
If you submit it, let us know at hn@ycombinator.com so we can put it in the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so it will get a random placement on HN's front page.
> 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…
Generally, the author makes some good points and there is definitely often a disconnect between academia and industry. I think it is important to remember that science is much more like a directed random walk toward an unknown goal. If industry wants specific answers to specific questions they could (should) finance the studies that provide them the answers. However, my impression is that when industry finances significant studies it is much more toward validating/confirming their already established practices, products... (the topic of these "bought" studies is another can of worms in the topics of academia and industry interactions)
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…
1. This is false. One of the reasons making bridges is so expensive is because each bridge is a precious special snowflake with lots of challenges specific to that bridge project and no other bridges.
2. Bridge building is a very small part of civil engineering, and civil engineering is a very small part of traditional engineering. Maybe software is more like process engineering, or chipset design, or subsystem integration, or workflow optimization.
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…
Yes, usually if you have a bad scene it rarely matters, if you have a lot of amazing ones too. And amazing actors, and editing, and ... Similarly, if you build a nice condo, if one face of it looks bad from the street, but the internal spacing of the units are great, then it's still a success. And if your checkout page is shit, but you have amazing search, good prices, great quality products, then your shop is generally great.
Of course this makes it sound like engineering, or a specific profession (like that of plumbing, HVAC, electrician tradespeople). It's always never an end in itself. It's complex like a bridge or a dam, sure, but without looking at the big picture (traffic, environment, costs, environment, etc..) it cannot be really evaluated. Even safety eval requires assumption (100 year floods, wind loads, min max temperature, max. traffic load, max ship height under the bridge, max electricity load).
And there are patterns, architectures, frameworks. (Like building codes.) There are audits (pentests, like the collision tests for new cars, or synthetic load testing for new sites).
The big difference is that usually movies are done in a few years. Scope change rarely affects bridges. After the basic outline of the dam is checked for basic structural sanity, it's done. After a condo master plan is approved the changes are minimal (because there have been many lives lost due to deviations from the plans).
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'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable... I would say universally that bugs found prior to shipping are lower cost (not just cost to fix) than those found after. I've heard from an auto industry friend that over-the-air update capabilities are becoming mandatory for more components. That sounds good because critica…
See: the disastrous technical state of many modern video games at launch, seemingly especially those extra chunky "live service" titles that are meant to be around for years instead of just a few months like a normal AAA single player game. Examples:
- https://kotaku.com/how-biowares-anthem-went-wrong-1833731964
- https://www.forbes.com/sites/insertcoin/2018/11/27/bethesdas...
- https://www.ign.com/articles/marvels-avengers-keeps-fixing-t...
No one would have dreamed of shipping a title on the Gamecube or Playstation 2 that had these kinds of problems— whatever it was you put on that day-one disc was going to be the game forever.
Greg Wilson is more positive. Though he does agree that nobody cares. https://third-bit.com/2021/07/17/software-engineerings-great...
That (or more likely https://www.youtube.com/watch?v=HrVtA-ue-x0 since that's where the info is) would make a good HN submission in its own right. Probably best to wait a few days to let the hivemind caches clear (followup/copycat posts aren't great: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... ). If you submit it, let us know at hn@ycombinator.com so we can put it in the second-chance pool ( https…