5 ms·

This is funny, considering that someone that worked on the defense industry (guide missile system) found a memory leak on one of their products, at that time. T

• mopsi 11mo ago
  ... until the extended-range version is ordered and no one remembers to fix the leak. :]
  • wizzwizz4 11mo ago
    They will remember, because it'll have been measured and documented, rigorously.
    • SketchySeaBeast 11mo ago
      I've found that the real trick with documentation isn't creation, it's discovery. I wonder how that information is easily found afterwards.
      • lloeki 11mo ago
        By reading the documentation thoroughly as a compulsory first step to designing the next system that depends on it. I realise this may probably boggle the mind of the modern software developer.
        • lukan 11mo ago
          You say this like trivial misstakes did not happen all the time in classical engineering as well. If there is a memory leak, them this is a flaw, that might not matter so much for a specific product, but I can also easily see it being forgotten, if it was maybe mentioned somewhere in the documentation, but maybe not clear enough and deadlines and stress to ship are a thing there as well.
        • hinkley 11mo ago
          That is not how this usually works. Most of the time QA can tell you exactly how the product works, regardless of what the documentation says. But many of us haven’t seen a QA team in five, ten years.
        • switchbak 11mo ago
          Just try harder. And if it still breaks, clearly you weren't trying hard enough! At some point you have to admit that humans are pretty bad at some things. Keeping documentation up to date and coherent is one of those things, especially in the age of TikTok. Better to live in the world we have and do the best you can, than to endlessly argue about how things should be but never will become.
          • vimwizard 11mo ago
            > especially in the age of TikTok Shouldn't grey beards, grizzled by years of practicing rigorous engineering, be passing this knowledge on to the next generation? How did they learn it when just starting out? They weren't born with it. Maybe engineering has actually improved so much that we only need to experience outages this frequently, and such feelings of nostalgia are born from never having to deal with systems having such high degrees of complexity and, realistically, 100% availability expectations on a global scale.
            • spockz 11mo ago
              They may not have learned it but being thorough in general was more of a thing. These days things are far more rushed. And I say that as a relatively young engineer. The amount of dedication and meticulous and concentrated work I know from older engineers when I started work and that I remember from my grand fathers is something I very rarely observe these days. Neither in engineering specific fields nor in general.
            • switchbak 11mo ago
              We were talking about making a missile (v2) with an extended range, and ensuring that the developers who work on it understand the assumption of the prior model: that it doesn't use free because it's expected to blow up before that would become an issue (a perfectly valid approach, I might add). And to ensure that this assumption still holds in the v2 extended range model. The analogy to Ariane 5 is very apt. Now, there can be tens of thousands of similar considerations to document. And keeping up that documentation with the actual state of the world is a full time job in itself. You can argue all you want that folks "should" do this or that, but all I've seen in my entire career is that documentation is almost universally: out of date, and not worth relying on because it's actively steering you in the wrong direction. And I actually disagree (as someone with some gray in my beard) with your premise that this is part of "rigorous engineering" as is practiced today. I wish it was, but the reality is you have to read the code, read it again, see what it does on your desk, see what it does in the wild, and still not trust it. We "should" be nice to each other, I "should" make more money, and it "should" be sunny more often. And we "should" have well written, accurate and reliable docs, but I'm too old to be waiting around for that day to come, especially in the age of zero attention and AI generated shite.
        • SkyPuncher 11mo ago
          I used to take this approach when building new integrations. Then I realized (1) most documentation sucks (2) there's far too much to remember (3) much of it is conditional (4) you don't always know what matters until it matters (e.g. using different paths of implementation). What works much better is having an intentional review step that you come back to.
      • hinkley 11mo ago
        If ownerless code doesn’t result in discoverability efforts then the whole thing goes off the rails. I won’t remember this block of code because five other people have touched it. So I need to be able to see what has changed and what it talks to so I can quickly verify if my old assumptions still hold true
      • wizzwizz4 11mo ago
        For the new system to be approved, you need to document the properties of the software component that are deemed relevant. The software system uses dynamic allocation, so "what do the allocation patterns look like? are there leaks, risks of fragmentation, etc, and how do we characterise those?" is on the checklist. The new developer could try to figure this all out from scratch, but if they're copying the old system's code, they're most likely just going to copy the existing paperwork, with a cursory check to verify that their modifications haven't changed the properties. They're going to see "oh, it leaks 3MiB per minute… and this system runs for twice as long as the old system", and then they're going to think for five seconds, copy-paste the appropriate paragraph, double the memory requirements in the new system's paperwork, and call it a day. Checklists work.
      • colechristensen 11mo ago
        >I wonder how that information is easily found afterwards. Military hardware is produced with engineering design practices that look nothing at all like what most of the HN crowd is used to. There is an extraordinary amount of documentation, requirements, and validation done for everything. There is a MIL-SPEC for pop tarts which defines all parts sizes, tolerances, etc. Unlike a lot in the software world military hardware gets DONE with design and then they just manufacture it.
      • pclmulqdq 11mo ago
        When people don't read the documentation, discovery is a real problem. When people do read the documentation, things are different. Many software engineers do not read the documentation, and then complain to you if they break something in a documented way. If you compare to hardware engineers, whose vendors put out tens of thousands of pages of documentation for single parts, they have a lot of skill at reading documentation (and the vendors at writing it).
    • hinkley 11mo ago
      Was this one measured and documented rigorously? Well obviously not, because the front fell off. That’s a dead giveaway.
  • hinkley 11mo ago
    Ariane 5 happens.
• Etheryte 11mo ago
  This paraphrased urban legend has nothing to do with quality engineering though? As described, it's designed to the spec and working as intended.
  • mikkupikku 11mo ago
    It tracks with my experience in software quality engineering. Asked to find problems with something already working well in the field. Dutifully find bugs/etc. Get told that it's working though so nobody will change anything. In dysfunctional companies, which is probably most of them, quality engineering exists to cover asses, not to actually guide development.
    • colechristensen 11mo ago
      It is not dysfunctional to ignore unreachable "bugs". A memory leak on a missile which won't be reached because it will explode long before that amount of time has passed is not a bug.
      • wkat4242 11mo ago
        It's a debt though. Because people will forget it's there and then at some point someone changes a counter from milliseconds to microseconds and then the issue happens 1000 times sooner. It's never right to leave structural issues even if "they don't happen under normal conditions".
        • Etheryte 11mo ago
          I don't think this argument makes sense. You wouldn't provision a 100GB server for a service where 1GB would do just in case unexpected conditions come up. If the requirements change, then the setup can change, doing it just because is wasteful. What if we forget is not a valid argument to over engineer and over provision.
          • datadrivenangel 11mo ago
• sally_glance 11mo ago
  Having observed an average of two mgmt rotations at most of the clients our company is working for this comes at absolutely no surprise to me. Engineering is acting perfectly reasonable, optimizing for cost and time within the constraints they were given. Constraints are updated at a (marketing or investor pleasure) whim without consulting engineering, cue disaster. Not even surprising to me anymore...
• runlaszlorun 11mo ago
  My hunch is that we do the same with memory leaks or other bugs in web applications where the time of a request is short.