9 ms·

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you ca

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

FalconSensei 3y ago
> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality
- colinmorelli 3y ago
  An infinite amount of time would not necessarily yield zero bugs. But more importantly, once you've fixed the "show-stopping bugs," putting the software in front of customers is probably the best next step, as even if it's bug-free, that doesn't mean it solves the problem well.
  - reactordev 3y ago
    there is no such thing as zero bugs. There is only a marker in time for a suite of tests that show no bugs. Doesn't mean larva aren't living under the wood. You can't control all the bits (unless you built your own hardware/software stack).
    - colinmorelli 3y ago
      I think we're saying the same thing? That was my point. You're never going to achieve zero bugs no matter how much time you give yourself. Focus on getting the critical path right and creating a good experience, and then get it to customers for feedback on where to go next. [The above does not necessarily apply in highly regulated industries or where lives are on the line]
      - ElectricalUnion 3y ago
        I would say that also applies on highly regulated industries or where lives are on the line. On those you're of course expected to do safety and testing up to the limit of the "value of a statistical life"s within the expected project impacts, but it still has time and budget limits.
        colinmorelli 3y ago
        The part I was suggesting does not apply is the statement "Focus on getting the critical path right and creating a good experience, and then get it to customers for feedback on where to go next." Most software engineering is about making sure the happy path works well. When lives are on the line, you need to also plan to minimize the possible damage that can happen when things go wrong.
      - BobaFloutist 3y ago
        I like to think of "zero bugs" as the asymptote. As you spend more time, you discover increasingly fewer (and less significant) bugs per unit of time. POSSIBLY at the limit of infinite time you hit 0 bugs, but even if you could, would it be worth it? Doubtful. I can think of far better ways to spend infinite time.
        zamalek 3y ago
        0 bugs is actually impossible. A cosmic ray can flip a bit and change the behavior of your software. We live in a fundamentally unreliable universe. We aren't taught how to write reliable software because very few people know how to write reliable software. It doesn't help that academia has a hard crush on OOP, which is a bag of accidental complexity - and complexity is a breeding ground for unreliability.
        BobaFloutist 3y ago
        I think if a cosmic ray flips the bit and changes the behavior of your software, you can still reasonably brag that you wrote 0-bug code. It's not your fault that happened, you didn't do that. The code you wrote had 0 bugs.
    - nonethewiser 3y ago
      > there is no such thing as zero bugs. Ok, I think we’ve gone too far. There absolutely is such thing as 0 bugs and sometimes code changes don’t have bugs. That is not to say it can be garunteed.
  - FalconSensei 3y ago
    > An infinite amount of time would not necessarily yield zero bugs. Never said that, just that quick turnaround for deliveries will usually mean more bugs, and having some extra time usually means less bugs
  - quickthrower2 3y ago
    We need to define bug but if bug is anything a customer (internal or external) is not happy with that passes triage and you can’t throw it back in their face. Then zero bugs would be impossible with even infinite time.
- nradov 3y ago
  That's only true up to a point. There are some quality assurance and control activities that are essentially "free" in that they actually allow for shipping faster by preventing rework. But that requires a high level of team maturity and process discipline, so some teams are simply incapable of doing it. And even in ideal circumstances it's impossible to ship defect free software (plus the endless discussions over whether particular issues are bugs or enhancement requests).
  - johnnyanmac 3y ago
    yeah, it's a spectrum. Clearly no one is expecting an app to be truly bug free if the underlying compiler itself has bugs. But how often do users truly run into compiler level bugs? I think when the author says "bug free", it's from the user perspective. where bugs either need to go out of your way to trigger or are so esoteric it's impossible to think about hitting without that user themself knowing the code inside out. Games is definitely an industry where the quality of code has always dipped to a point where users can easily hit issues in normal use, and only gets worse as games get more complex. That's where it gets truly intolerable
  - FalconSensei 3y ago
    There are tools that help, but you still need time to integrate those tools, learn how to use them, etc. If you are doing unit and integration tests, you need time to not only write those, but also actually plan your tests, and learn how to write tests. Which... needs time
- d0gsg0w00f 3y ago
  Like the age old builder trope. "Cheap. Fast. Good. Pick two."
  - NegativeK 3y ago
    That's the optimistic viewpoint. The pessimistic viewpoint is that you get to pick up to one.
OnlyMortal 3y ago
Correct. As I like to tell my team, if I’ve typed something I’ve caused a bug. It’s all about risk. I assume I’m not infallible. Writing some unit tests, C++ and mocking in my case, give both the team and myself some confidence I’ve not made things worse. I’m the most experienced dev in the department.
reactordev 3y ago
This kind of wisdom only comes from experience I think. Either that or higher order think. Like the article says, most of the time testing/tdd/qa is bolt on after-the-fact. Or a big push at the end with "QA Sprints" (are you sprinting or are you examining? what exactly is a QA sprint? I know what it is). Once you get beyond "I wrote a function" and "I tested a function" and even still "I tested a function that was called by a function over the wire", you will come to a realization that no matter how edgy your edge cases, no matter how thorough your QA, there will always - ALWAYS be 0-day "undefined behavior" in certain configurations. On certain hardware. On certain kernels. It's an assurance that I guarantee that I'm almost positive it's bug free, since it passed tests, it passed human eyes, and it passed review - fingers crossed.
chopsuey5540 3y ago
You might be correct today but that’s a pretty sad state of affairs, don’t you think we can do better? Most other engineering domains can deliver projects without bugs, with various definitions of “bug” of course
- deleted 3y ago
  [deleted]
- KeplerBoy 3y ago
  I'm not sure about that. Which engineering domain do you have in mind? Maybe show-stopping bugs are somewhat unique to software engineering, but all somewhat-complex products are flawed to some extent imho. It might be an unergonomic handle on a frying pan, furniture that visibly warps under the slightest load (looking at ikea shelfing) or the lettering coming off the frequently used buttons on a coffee machine.
  - bee_rider 3y ago
    But there do exist shelves that don’t warp, when used within some reasonable bounds. I’d also quibble about the buttons on the coffee machine. They might be properly designed, just subject to the normal wear-and-tear that is inevitable in the real world. This is not a defect, physical devices have finite lifespans. As far as computers go… if we got to the point where the main thing that killed our programs was the hard drives falling apart and capacitors drying out, that would be quite impressive and I think everyone would be a little bit less critical of the field.
    - saled 3y ago
      Formally verified, bug free software exists. It just costs a LOT to produce, and typically isn't worth it, except for things like cryptographic libraries and life or death systems. As the discipline has evolved, the high integrity tools are slowly being incorporated into typical languages and IDEs to generally improve quality cheaper. Compare C++ to rust for example, whole classes of bugs are impossible (or much harder to make) in rust.
    - 3y ago
fidotron 3y ago
It is sad that people on here would believe this and that for whole platforms it is actually true, however, it absolutely is not universally true and the proof is all around us.
- sanderjd 3y ago
  What proof is all around us?
  - fidotron 3y ago
    The amount of software in everyday objects which runs without exhibiting bugs to such a degree we do not notice most of it even exists.
    - sanderjd 3y ago
      Yes, but that software is not bug-free. The claim was not "it's impossible to make software that does not exhibit bugs too a casually noticeable degree". People who know how the sausage is made will always know of a bunch of bugs that haven't been fixed exactly because they aren't impactful enough to be worth the effort required to fix them.
      - fidotron 3y ago
        If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.
        digging 3y ago
        > If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.
jasondigitized 3y ago
It's perfectly acceptable to let bugs escape into production if those "cost" of fixing that bug higher than the "cost" to the user experience / job to be done. A bug that takes a week to fix that will only be encountered by a small amount of users in a small number of obscure scenarios may not need to be fixed.
- AlotOfReading 3y ago
  This presupposes that you know what/where bugs will be found and how they'll impact future users. In my experience knowing either of these is very rare at the point where you're "building quality".
  - xkekjrktllss 3y ago
    >how they'll impact future users Most people in this thread understand that users' interests only matter insofar as they impact business profit. I just think you're having a different conversation.
- billti 3y ago
  I think a common error is taking this view in isolation on each bug. Fact is, if you ship enough 'low probability' bugs in your product, your probabilities still add up to a point where many customers are going to hit several of them. I've used plenty of products that suffer from 'death by a thousands cuts'. Are the bugs I hit "ship blockers"? No. Do I hit enough of them that the product sucks and I don't want to use it? Absolutely.
  - pixl97 3y ago
    Software is commonly built on non-fungible components and monopolies. Right, you don't want to use Microsoft Word, or SalesForce, or Apple vs Android, or X Whatever. It's highly unlikely you'll have a choice if you use it though.
  - owlbite 3y ago
    Very much this, and low risk bugs compound at scale. If you're in a very large FANNG type company, and say you have 1000 components that each ship 1 bug each day that has a 0.1% chance of breaking something critical, that translates to a less than 50% chance you ship a working OS on any given day. And that may mean the entire company's productivity is impacted for the day depending on how broken it is.
Dalewyn 3y ago
A saying that I once heard and appreciate goes like this: "A programmer who releases buggy software and fixes them is better than a programmer who always releases perfect software in one shot, because the latter doesn't know how to fix bugs." Perhaps similar to the saying that a good driver will miss a turn, but a bad driver never misses one.
- MaxBarraclough 3y ago
  That's backward. A successful software development methodology will tend to catch bugs early in the development pipeline. The doesn't know how to fix bugs idea seems pretty silly.
  - Dalewyn 3y ago
    I think you misunderstand, I'm talking about a programmer who makes perfect, bug-free code in one shot. There are no bugs to catch and fix, because this "perfect" programmer never writes buggy code. The moral of the sayings is, that "perfect" programmer is actually a bad programmer because he wouldn't know how to fix bugs by virtue of never needing to deal with them. To reuse the driver analogy, the driver who never misses a turn is a bad driver because he doesn't know what to do when he does miss a turn.
    - MaxBarraclough 3y ago
      I don't see that I misunderstood anything. If a software developer consistently delivers high-quality software on time and on budget, that means they're good at their job, pretty much by definition. It would make no sense to infer they're bad at fixing bugs. It would make sense to infer instead that they're good at catching and fixing bugs prior to release, which is what we want from a software development process. > the driver who never misses a turn is a bad driver because he doesn't know what to do when he does miss a turn Missing a turn during a driving test will never improve your odds of passing. The driver who never misses a turn presumably has excellent awareness and will be well equipped to deal with a mistake should they make one. They also probably got that way by missing plenty of turns when they were less experienced.
codegeek 3y ago
Yep. If you have written production grade software at real companies, you know that the moment you make that new commit (even if 1 liner change), you are now ready to accept that it could break something. yes you can do your unit tests, integration test, User Acceptance Tests and what not. But every code change = new possible bug that you may not be able to catch until it occurs to a customer. Whenever I hear a developer say "I never ship buggy code", I am always cautious to dig in more and understand what they mean by that.
- Gare 3y ago
  How about a formal proof? :) I jest, but that should be the gold standard for anything life-critical and good to have for mission-critical software. Alas, we're not there yet.
  - underlipton 3y ago
    Oh, boy, I get to post this again: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
  - akhosravian 3y ago
    I’m not a CS academic or a mathematician, but don’t Godel’s incompleteness theorems preclude a formal proof of correctness?
    - topaz0 3y ago
      No. There are plenty of things that can be proved, it's just that there exist true statements that cannot be proved.
      - kevindamm 3y ago
        That's closer, but still not quite right. There are well-formed statements that can be proved but which assert that its godelized value represents a non-provable theorem. Therefore, you must accept that it and its contradiction are both provable (leading to an inconsistent system), or not accept it and now there are provable theorems that cannot be expressed in the system. Furthermore, that this can be constructed from anything with base arithmetic and induction over first-order logic (Gödel's original paper included how broadly it could be applied to basically every logical system).
datadeft 3y ago
Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?
- alexchamberlain 3y ago
  Most engineering domains expect failure; the fail safes, checklists etc prevent it causing real damage.
- Gud 3y ago
  Trust me when I say this: even "other" engineering domains have to do patches. The difference is that software can be used before it is fully ready, and it makes sense to do so. No one can really use a 90% finished power plant, but software at 95% capacity is still usually "good enough"
  - omginternets 3y ago
    e.g. product recalls?
    - Gud 3y ago
      I install high voltage switchgear on site. A common problem is all the changes that has been added during the design stage, circuits that have been removed or altered, work that has kind of mostly been done to the schemes by the overworked secondary engineer. Sometimes, the schemes have been changed after all the wiring is completed and shipped to site, making it my pain in the ass when it's time to do the commissioning. The end result is never 100% perfect, but somewhere in between "not too bad" and "good enough".
  - daotoad 3y ago
    I think you're 90% there. There is also the cost to apply a patch. If you want to patch a bridge, it's gonna cost you. Even if you only need to close down a single lane of traffic for a few hours you are looking at massive expenses for traffic control, coordination with transportation agencies, etc. For most software it's pretty inexpensive to ship updates. If you're a SaaS company regular updates are just part of your business model. So the software is never actually done. We just keep patching and patching. In some contexts, it is much more expensive to push out updates. For example, in the 00s, I worked on a project that had weather sensors installed in remote locations in various countries and the only way to get new software to them was via dial-up. And we were luck that that was even an option. Making international long distance calls to upload software patches over a 9600 baud connection is expensive. So we tested our code religiously before even considering an update, and we only pushed out the most direly needed patches. Working on SaaS these days and the approach is "roll forward through bugs". It just makes more economic sense with the cost structures in this business.
fivre 3y ago
it will be necessary to deliver software without bugs that could have reasonably been avoided in time ive had this sentiment thrown at me too often by peak move fast and break things types. it's too often a cudgel to dispense with all QA in favor of more new feature development. shipping shit that has the same pattern of flaws youve encountered in the past when youve been shown ways to catch them early but couldnt be bothered isnt accepting that you cant catch everything, it's creating a negative externality. you usually can make it someone else's problem and abscond with the profits despite, but that doesn't mean you should
HeyLaughingBoy 3y ago
Nothing is bug free. Not buildings, not bridges, not cars, not airplanes, not software. There are mistakes in every field of engineering and the best we can hope for is to minimize them as much as possible. Engineering is knowing (among other things) how to categorize the potential mistakes, develop procedures to reduce the chance of them being made and in the case that some slip through (and they will), estimate their impact and decide when you're "good enough." Software engineering is no different.
rocqua 3y ago
I think with formal analysis, whole bug classes can be eliminated. Add to that a rigorous programming style, and 'bug-free' code is within reach. There will remain bugss that make it through, but they will be rare, and will need a chain of mistakes. Currently ways of coding to this kind of standard exist. But they are stupid. It involves things like no dynamic memory allocation, only fixed length for-loops, and other very strict rules. These are used in aerospace, where bugs are rather costly and rare.
- kaba0 3y ago
  What seems to yield much better results is to have the program be built by two separate teams to a standard. Then both programs can be run simultaneously, checking each others output — I believe something like this is actually used in the aerospace industry.
sublimefire 3y ago
Reminds me of a story about an engineer who was participating in a meeting with managers and partners. Manager was speaking of his team and how they will deliver software. Then, he asked the engineer to assure that the software will be bug-free. To this the engineer responded by saying he cannot guarantee there will be no bugs. The manager went nuts and started screaming. Engineers cannot be responsible for all the vertical stack and the components which were built by others. If somebody claims it is bug free then they have not enough experience. Pretty much anything can fail, we just need to test as many possible cases as possible with a variety of available tools to reduce the chances of bugs.

FalconSensei 3y ago

> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality

colinmorelli 3y ago
An infinite amount of time would not necessarily yield zero bugs. But more importantly, once you've fixed the "show-stopping bugs," putting the software in front of customers is probably the best next step, as even if it's bug-free, that doesn't mean it solves the problem well.
- reactordev 3y ago
  there is no such thing as zero bugs. There is only a marker in time for a suite of tests that show no bugs. Doesn't mean larva aren't living under the wood. You can't control all the bits (unless you built your own hardware/software stack).
  - colinmorelli 3y ago
    I think we're saying the same thing? That was my point. You're never going to achieve zero bugs no matter how much time you give yourself. Focus on getting the critical path right and creating a good experience, and then get it to customers for feedback on where to go next. [The above does not necessarily apply in highly regulated industries or where lives are on the line]
    - ElectricalUnion 3y ago
      I would say that also applies on highly regulated industries or where lives are on the line. On those you're of course expected to do safety and testing up to the limit of the "value of a statistical life"s within the expected project impacts, but it still has time and budget limits.
      - colinmorelli 3y ago
        The part I was suggesting does not apply is the statement "Focus on getting the critical path right and creating a good experience, and then get it to customers for feedback on where to go next." Most software engineering is about making sure the happy path works well. When lives are on the line, you need to also plan to minimize the possible damage that can happen when things go wrong.
    - BobaFloutist 3y ago
      I like to think of "zero bugs" as the asymptote. As you spend more time, you discover increasingly fewer (and less significant) bugs per unit of time. POSSIBLY at the limit of infinite time you hit 0 bugs, but even if you could, would it be worth it? Doubtful. I can think of far better ways to spend infinite time.
      - zamalek 3y ago
        0 bugs is actually impossible. A cosmic ray can flip a bit and change the behavior of your software. We live in a fundamentally unreliable universe. We aren't taught how to write reliable software because very few people know how to write reliable software. It doesn't help that academia has a hard crush on OOP, which is a bag of accidental complexity - and complexity is a breeding ground for unreliability.
        BobaFloutist 3y ago
        I think if a cosmic ray flips the bit and changes the behavior of your software, you can still reasonably brag that you wrote 0-bug code. It's not your fault that happened, you didn't do that. The code you wrote had 0 bugs.
  - nonethewiser 3y ago
    > there is no such thing as zero bugs. Ok, I think we’ve gone too far. There absolutely is such thing as 0 bugs and sometimes code changes don’t have bugs. That is not to say it can be garunteed.
- FalconSensei 3y ago
  > An infinite amount of time would not necessarily yield zero bugs. Never said that, just that quick turnaround for deliveries will usually mean more bugs, and having some extra time usually means less bugs
- quickthrower2 3y ago
  We need to define bug but if bug is anything a customer (internal or external) is not happy with that passes triage and you can’t throw it back in their face. Then zero bugs would be impossible with even infinite time.
nradov 3y ago
That's only true up to a point. There are some quality assurance and control activities that are essentially "free" in that they actually allow for shipping faster by preventing rework. But that requires a high level of team maturity and process discipline, so some teams are simply incapable of doing it. And even in ideal circumstances it's impossible to ship defect free software (plus the endless discussions over whether particular issues are bugs or enhancement requests).
- johnnyanmac 3y ago
  yeah, it's a spectrum. Clearly no one is expecting an app to be truly bug free if the underlying compiler itself has bugs. But how often do users truly run into compiler level bugs? I think when the author says "bug free", it's from the user perspective. where bugs either need to go out of your way to trigger or are so esoteric it's impossible to think about hitting without that user themself knowing the code inside out. Games is definitely an industry where the quality of code has always dipped to a point where users can easily hit issues in normal use, and only gets worse as games get more complex. That's where it gets truly intolerable
- FalconSensei 3y ago
  There are tools that help, but you still need time to integrate those tools, learn how to use them, etc. If you are doing unit and integration tests, you need time to not only write those, but also actually plan your tests, and learn how to write tests. Which... needs time
d0gsg0w00f 3y ago
Like the age old builder trope. "Cheap. Fast. Good. Pick two."
- NegativeK 3y ago
  That's the optimistic viewpoint. The pessimistic viewpoint is that you get to pick up to one.

OnlyMortal 3y ago

Correct. As I like to tell my team, if I’ve typed something I’ve caused a bug. It’s all about risk. I assume I’m not infallible. Writing some unit tests, C++ and mocking in my case, give both the team and myself some confidence I’ve not made things worse. I’m the most experienced dev in the department.

reactordev 3y ago

This kind of wisdom only comes from experience I think. Either that or higher order think. Like the article says, most of the time testing/tdd/qa is bolt on after-the-fact. Or a big push at the end with "QA Sprints" (are you sprinting or are you examining? what exactly is a QA sprint? I know what it is). Once you get beyond "I wrote a function" and "I tested a function" and even still "I tested a function that was called by a function over the wire", you will come to a realization that no matter how edgy your edge cases, no matter how thorough your QA, there will always - ALWAYS be 0-day "undefined behavior" in certain configurations. On certain hardware. On certain kernels. It's an assurance that I guarantee that I'm almost positive it's bug free, since it passed tests, it passed human eyes, and it passed review - fingers crossed.

chopsuey5540 3y ago

You might be correct today but that’s a pretty sad state of affairs, don’t you think we can do better? Most other engineering domains can deliver projects without bugs, with various definitions of “bug” of course

deleted 3y ago
[deleted]
KeplerBoy 3y ago
I'm not sure about that. Which engineering domain do you have in mind? Maybe show-stopping bugs are somewhat unique to software engineering, but all somewhat-complex products are flawed to some extent imho. It might be an unergonomic handle on a frying pan, furniture that visibly warps under the slightest load (looking at ikea shelfing) or the lettering coming off the frequently used buttons on a coffee machine.
- bee_rider 3y ago
  But there do exist shelves that don’t warp, when used within some reasonable bounds. I’d also quibble about the buttons on the coffee machine. They might be properly designed, just subject to the normal wear-and-tear that is inevitable in the real world. This is not a defect, physical devices have finite lifespans. As far as computers go… if we got to the point where the main thing that killed our programs was the hard drives falling apart and capacitors drying out, that would be quite impressive and I think everyone would be a little bit less critical of the field.
  - saled 3y ago
    Formally verified, bug free software exists. It just costs a LOT to produce, and typically isn't worth it, except for things like cryptographic libraries and life or death systems. As the discipline has evolved, the high integrity tools are slowly being incorporated into typical languages and IDEs to generally improve quality cheaper. Compare C++ to rust for example, whole classes of bugs are impossible (or much harder to make) in rust.
  - 3y ago

fidotron 3y ago

It is sad that people on here would believe this and that for whole platforms it is actually true, however, it absolutely is not universally true and the proof is all around us.

sanderjd 3y ago
What proof is all around us?
- fidotron 3y ago
  The amount of software in everyday objects which runs without exhibiting bugs to such a degree we do not notice most of it even exists.
  - sanderjd 3y ago
    Yes, but that software is not bug-free. The claim was not "it's impossible to make software that does not exhibit bugs too a casually noticeable degree". People who know how the sausage is made will always know of a bunch of bugs that haven't been fixed exactly because they aren't impactful enough to be worth the effort required to fix them.
    - fidotron 3y ago
      If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.
      - digging 3y ago
        > If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.

jasondigitized 3y ago

It's perfectly acceptable to let bugs escape into production if those "cost" of fixing that bug higher than the "cost" to the user experience / job to be done. A bug that takes a week to fix that will only be encountered by a small amount of users in a small number of obscure scenarios may not need to be fixed.

AlotOfReading 3y ago
This presupposes that you know what/where bugs will be found and how they'll impact future users. In my experience knowing either of these is very rare at the point where you're "building quality".
- xkekjrktllss 3y ago
  >how they'll impact future users Most people in this thread understand that users' interests only matter insofar as they impact business profit. I just think you're having a different conversation.
billti 3y ago
I think a common error is taking this view in isolation on each bug. Fact is, if you ship enough 'low probability' bugs in your product, your probabilities still add up to a point where many customers are going to hit several of them. I've used plenty of products that suffer from 'death by a thousands cuts'. Are the bugs I hit "ship blockers"? No. Do I hit enough of them that the product sucks and I don't want to use it? Absolutely.
- pixl97 3y ago
  Software is commonly built on non-fungible components and monopolies. Right, you don't want to use Microsoft Word, or SalesForce, or Apple vs Android, or X Whatever. It's highly unlikely you'll have a choice if you use it though.
- owlbite 3y ago
  Very much this, and low risk bugs compound at scale. If you're in a very large FANNG type company, and say you have 1000 components that each ship 1 bug each day that has a 0.1% chance of breaking something critical, that translates to a less than 50% chance you ship a working OS on any given day. And that may mean the entire company's productivity is impacted for the day depending on how broken it is.

Dalewyn 3y ago

A saying that I once heard and appreciate goes like this: "A programmer who releases buggy software and fixes them is better than a programmer who always releases perfect software in one shot, because the latter doesn't know how to fix bugs." Perhaps similar to the saying that a good driver will miss a turn, but a bad driver never misses one.

MaxBarraclough 3y ago
That's backward. A successful software development methodology will tend to catch bugs early in the development pipeline. The doesn't know how to fix bugs idea seems pretty silly.
- Dalewyn 3y ago
  I think you misunderstand, I'm talking about a programmer who makes perfect, bug-free code in one shot. There are no bugs to catch and fix, because this "perfect" programmer never writes buggy code. The moral of the sayings is, that "perfect" programmer is actually a bad programmer because he wouldn't know how to fix bugs by virtue of never needing to deal with them. To reuse the driver analogy, the driver who never misses a turn is a bad driver because he doesn't know what to do when he does miss a turn.
  - MaxBarraclough 3y ago
    I don't see that I misunderstood anything. If a software developer consistently delivers high-quality software on time and on budget, that means they're good at their job, pretty much by definition. It would make no sense to infer they're bad at fixing bugs. It would make sense to infer instead that they're good at catching and fixing bugs prior to release, which is what we want from a software development process. > the driver who never misses a turn is a bad driver because he doesn't know what to do when he does miss a turn Missing a turn during a driving test will never improve your odds of passing. The driver who never misses a turn presumably has excellent awareness and will be well equipped to deal with a mistake should they make one. They also probably got that way by missing plenty of turns when they were less experienced.

codegeek 3y ago

Yep. If you have written production grade software at real companies, you know that the moment you make that new commit (even if 1 liner change), you are now ready to accept that it could break something. yes you can do your unit tests, integration test, User Acceptance Tests and what not. But every code change = new possible bug that you may not be able to catch until it occurs to a customer. Whenever I hear a developer say "I never ship buggy code", I am always cautious to dig in more and understand what they mean by that.

Gare 3y ago
How about a formal proof? :) I jest, but that should be the gold standard for anything life-critical and good to have for mission-critical software. Alas, we're not there yet.
- underlipton 3y ago
  Oh, boy, I get to post this again: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
- akhosravian 3y ago
  I’m not a CS academic or a mathematician, but don’t Godel’s incompleteness theorems preclude a formal proof of correctness?
  - topaz0 3y ago
    No. There are plenty of things that can be proved, it's just that there exist true statements that cannot be proved.
    - kevindamm 3y ago
      That's closer, but still not quite right. There are well-formed statements that can be proved but which assert that its godelized value represents a non-provable theorem. Therefore, you must accept that it and its contradiction are both provable (leading to an inconsistent system), or not accept it and now there are provable theorems that cannot be expressed in the system. Furthermore, that this can be constructed from anything with base arithmetic and induction over first-order logic (Gödel's original paper included how broadly it could be applied to basically every logical system).

datadeft 3y ago

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

alexchamberlain 3y ago
Most engineering domains expect failure; the fail safes, checklists etc prevent it causing real damage.
Gud 3y ago
Trust me when I say this: even "other" engineering domains have to do patches. The difference is that software can be used before it is fully ready, and it makes sense to do so. No one can really use a 90% finished power plant, but software at 95% capacity is still usually "good enough"
- omginternets 3y ago
  e.g. product recalls?
  - Gud 3y ago
    I install high voltage switchgear on site. A common problem is all the changes that has been added during the design stage, circuits that have been removed or altered, work that has kind of mostly been done to the schemes by the overworked secondary engineer. Sometimes, the schemes have been changed after all the wiring is completed and shipped to site, making it my pain in the ass when it's time to do the commissioning. The end result is never 100% perfect, but somewhere in between "not too bad" and "good enough".
- daotoad 3y ago
  I think you're 90% there. There is also the cost to apply a patch. If you want to patch a bridge, it's gonna cost you. Even if you only need to close down a single lane of traffic for a few hours you are looking at massive expenses for traffic control, coordination with transportation agencies, etc. For most software it's pretty inexpensive to ship updates. If you're a SaaS company regular updates are just part of your business model. So the software is never actually done. We just keep patching and patching. In some contexts, it is much more expensive to push out updates. For example, in the 00s, I worked on a project that had weather sensors installed in remote locations in various countries and the only way to get new software to them was via dial-up. And we were luck that that was even an option. Making international long distance calls to upload software patches over a 9600 baud connection is expensive. So we tested our code religiously before even considering an update, and we only pushed out the most direly needed patches. Working on SaaS these days and the approach is "roll forward through bugs". It just makes more economic sense with the cost structures in this business.

fivre 3y ago

it will be necessary to deliver software without bugs that could have reasonably been avoided in time ive had this sentiment thrown at me too often by peak move fast and break things types. it's too often a cudgel to dispense with all QA in favor of more new feature development. shipping shit that has the same pattern of flaws youve encountered in the past when youve been shown ways to catch them early but couldnt be bothered isnt accepting that you cant catch everything, it's creating a negative externality. you usually can make it someone else's problem and abscond with the profits despite, but that doesn't mean you should

HeyLaughingBoy 3y ago

Nothing is bug free. Not buildings, not bridges, not cars, not airplanes, not software. There are mistakes in every field of engineering and the best we can hope for is to minimize them as much as possible. Engineering is knowing (among other things) how to categorize the potential mistakes, develop procedures to reduce the chance of them being made and in the case that some slip through (and they will), estimate their impact and decide when you're "good enough." Software engineering is no different.

rocqua 3y ago

I think with formal analysis, whole bug classes can be eliminated. Add to that a rigorous programming style, and 'bug-free' code is within reach. There will remain bugss that make it through, but they will be rare, and will need a chain of mistakes. Currently ways of coding to this kind of standard exist. But they are stupid. It involves things like no dynamic memory allocation, only fixed length for-loops, and other very strict rules. These are used in aerospace, where bugs are rather costly and rare.

kaba0 3y ago
What seems to yield much better results is to have the program be built by two separate teams to a standard. Then both programs can be run simultaneously, checking each others output — I believe something like this is actually used in the aerospace industry.

sublimefire 3y ago

Reminds me of a story about an engineer who was participating in a meeting with managers and partners. Manager was speaking of his team and how they will deliver software. Then, he asked the engineer to assure that the software will be bug-free. To this the engineer responded by saying he cannot guarantee there will be no bugs. The manager went nuts and started screaming. Engineers cannot be responsible for all the vertical stack and the components which were built by others. If somebody claims it is bug free then they have not enough experience. Pretty much anything can fail, we just need to test as many possible cases as possible with a variety of available tools to reduce the chances of bugs.