5 ms·

After 15 years of software development experience, I've been thinking about this a lot lately. It's like you don't stop learning to be more careful. Even after

After 15 years of software development experience, I've been thinking about this a lot lately. It's like you don't stop learning to be more careful. Even after 15 years, my mind is expanding. Sometimes I find code that I wrote 2 years ago which, at the time, was produced with far more care and extreme pedantic attention to detail than the average developer would have given it, yet it was still not correct for ALL POSSIBLE edge cases. It's insanely difficult to produce correct code. I'm starting to have thoughts like "Has anyone in the world (aside from Knuth haha) written a single program which is over 10K lines of code and which is 100% bug free right now? Does such program exist?" I don't even believe that Bitcoin is bug free; it just has too many lines.

behnamoh 3y ago
> which is 100% bug free define "bug free". In Python, I've been reimplementing monads recently. It's such a shame that Python still doesn't have Null/None propagation. After each obtained result and before using it in the next chain, I have to run a series of sanity checks (is it Null or not, etc.) which should be resolved automatically by the language. Alas, most people don't care. Something like this would be nice: result =? foo(bar :? str) meaning that foo should receive a str bar, but maybe bar is not str. Then foo should return something, but maybe it returns None (the =? part).
- unnouinceput 3y ago
  Something like that would fail the code review at any large organization. Why? Because ternary operator is hard for maintenance purposes so the reviewer would simply ask to use if..else syntax instead. I gather you never worked in such organization.
  - paganel 3y ago
    Not the OP and not a fan of ternary operations, but if programming were left to large organizations we would still be writing .asp pages. Which is to say that inovation happens only when you try to do stuff just a little different each time, so I’d say that code reviews as currently implemented at those big organizations is against long-term programming-related innovation.
  - thewakalix 3y ago
    That is not the ternary operator.
    - wruza 3y ago
      But following the setting of the gp comment, that operator would fail code review as well. Because the book of sacred rituals says so.
- benrutter 3y ago
  This is an interesting idea- I'm not sure I understand it fully though. Do you have much luck with static type analysis? I find in Python, nothings ever certain, but mypy with good type hints solves a lot of these kind of None based shenanigans.
  - behnamoh 3y ago
    I have heard about mypy but haven't seriously used it. Type hinting has helped a lot (basically you'll end up writing Python like it's Rust), but something like the Maybe monad (my example above) would reduce a lot of boilerplate.
fiddlerwoaroof 3y ago
I don’t know about bug free, but Code Complete claims that the space shuttle project shipped a million lines of code with no bugs in production.
irjustin 3y ago
Bug free code isn't pragmatic at all. For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases. One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200".
- indemnity 3y ago
  Another almost worst thing is having production environments with significantly different stacks to what you are using locally, with branches in the code to account for this. This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. And it deploys from one of our old crappy Jenkins pipelines that decided 30 minutes ago to start having a failing volume. Should have just used GitHub Actions + Postgres.
  - 0xDEAFBEAD 3y ago
    >This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. Did you consider running a second test instance of the DB in the cloud?
    - indemnity 3y ago
      > Did you consider running a second test instance of the DB in the cloud? This is using the test instance :) The issue replicates both on prod (cloud) and test (cloud). But not locally. So a nice 30 minute deployment pipeline run to test if your fix worked, since we are firewalled from direct DB connections from local dev machines, even for test instances.
      - john_the_writer 3y ago
lmm 3y ago
Somewhere Edward Kmett has a great post about how he realised he was just writing buggy code that would have to be thrown again away and away, and that was the point where he switched to writing Haskell libraries that were perfect and could live forever.
raincole 3y ago
Bug-free is more about how narrow the spec is. Can your GUI app works on a Windows 95 with Polish as the system langauge while using a Chinese input method, and the user holding Alt all the time? Probably not. But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case?
- lelanthran 3y ago
  > But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case? I don't even think it is necessary to ask that question. The only question that should be asked for something like this is "How do we handle all unsupported use-cases?" Because then it becomes simpler, when an edge-case causes the software to freeze, to detect for that edge-case and hand it off to the "not supported" handler. In the best case scenario, we simply detect whether the use-case is supported and then either proceed or hand control to the not-supported-handler. In the worst case scenario, when the bug report comes in, we don't even bother trying to reproduce it, we just add a general check for it and move on to the not-supported-handler. In this particular case, the detection can do any one of the following: 1. Check for english, and if not, display "unsupported language". 2. Check that input language and system language match, or display unsupported". 3. Check that the OS is supported, display "unsupported OS" if not. 4. Check that the input is valid (i.e. no special codes, whether by holding down halt or otherwise), or display "unsupported input". Whether the spec is narrow or wide, the developer needs to do the work to ensure that the user is running within spec. Not checking results in more "bugs" that are, as you said, use-cases which shouldn't be supported anyway.
  - pixl97 3y ago
    >"How do we handle all unsupported use-cases?" Until you find out that your operating system handles 95% of unsupported cases in one way, then uses a hidden API to deal with the weirdness of other languages and the unsupported case isn't detected in that last 5% of languages. Of course that never came up in testing because who uses a hebrew/japanese combination and now the error message being returned by your application has nothing to do with the actual problem. Your worst case scenario is just the common edge case bug handling that support/QA/dev's handle every day.
63 3y ago
I think about this pretty often from the opposite perspective. As a frequent user of software, I can't get over how much it all sucks. Nearly every nontrivial piece of software I've ever used has had annoying and frustrating bugs and it feels to me like that's only getting worse. I agree that there's no correct software and I think the software engineering discipline needs to be blamed more for it. I don't think we deserve these salaries just to churn out broken code. I love programming but you can bet that the second there's an AI that can write perfect code, I'm advocating for it to replace us all because I'm tired of broken software.
- pvdoom 3y ago
  Well, there is a massive force that acts directly against not doing broken code - people(read managers and stakeholders) don't want to wait, they want the value for their money now, and from their perspective a certain degree of brokenness is fine
  - pixl97 3y ago
    As long as it works "well enough" a broken product that ships now is better than a perfect product that never ships.
    - pvdoom 3y ago
      Yes, but also this very easily turns into shipping absolute crap, that in itself can cause a good concept to flop. There is a balance to be had, and at least some decent minimum requirements on what is good enough to ship. You neither want to overdosing, nor ship the first draft that sort of kinda works, and that second thing happens way too often.
- ozim 3y ago
  What software are you using and what were last 10 frustrating bugs you encountered? I find it fascinating because my use of software seems bug free in last 5-10 years. It is hard for me to run nowadays into a frustrating bug. When I was in high school there were just loads of bugs and everything seemed broken it was 2005ish and before. Windows was crashing now and again, had to reinstall frequently, software was crashing taking my work with it so I still have compulsive ctrl-s tick.
PH95VuimJjqBqy 3y ago
The goal isn't to produce perfect code, the goal is to evolve to perfect code. This gets missed by so many developers, once you change your mindset on this, you'll find you write better software. One of the questions to ask when writing code is "how long will it take to discover if this goes wrong?". Make it quick to find, let someone else in the future deal with the imperfections. I'm not saying don't try for perfect code, I'm saying not having written perfect code isn't a problem and it isn't a failing. code evolves to be stable, it is not born that way.

behnamoh 3y ago

> which is 100% bug free define "bug free". In Python, I've been reimplementing monads recently. It's such a shame that Python still doesn't have Null/None propagation. After each obtained result and before using it in the next chain, I have to run a series of sanity checks (is it Null or not, etc.) which should be resolved automatically by the language. Alas, most people don't care. Something like this would be nice: result =? foo(bar :? str) meaning that foo should receive a str bar, but maybe bar is not str. Then foo should return something, but maybe it returns None (the =? part).

unnouinceput 3y ago
Something like that would fail the code review at any large organization. Why? Because ternary operator is hard for maintenance purposes so the reviewer would simply ask to use if..else syntax instead. I gather you never worked in such organization.
- paganel 3y ago
  Not the OP and not a fan of ternary operations, but if programming were left to large organizations we would still be writing .asp pages. Which is to say that inovation happens only when you try to do stuff just a little different each time, so I’d say that code reviews as currently implemented at those big organizations is against long-term programming-related innovation.
- thewakalix 3y ago
  That is not the ternary operator.
  - wruza 3y ago
    But following the setting of the gp comment, that operator would fail code review as well. Because the book of sacred rituals says so.
benrutter 3y ago
This is an interesting idea- I'm not sure I understand it fully though. Do you have much luck with static type analysis? I find in Python, nothings ever certain, but mypy with good type hints solves a lot of these kind of None based shenanigans.
- behnamoh 3y ago
  I have heard about mypy but haven't seriously used it. Type hinting has helped a lot (basically you'll end up writing Python like it's Rust), but something like the Maybe monad (my example above) would reduce a lot of boilerplate.

fiddlerwoaroof 3y ago

I don’t know about bug free, but Code Complete claims that the space shuttle project shipped a million lines of code with no bugs in production.

irjustin 3y ago

Bug free code isn't pragmatic at all. For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases. One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200".

indemnity 3y ago
Another almost worst thing is having production environments with significantly different stacks to what you are using locally, with branches in the code to account for this. This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. And it deploys from one of our old crappy Jenkins pipelines that decided 30 minutes ago to start having a failing volume. Should have just used GitHub Actions + Postgres.
- 0xDEAFBEAD 3y ago
  >This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. Did you consider running a second test instance of the DB in the cloud?
  - indemnity 3y ago
    > Did you consider running a second test instance of the DB in the cloud? This is using the test instance :) The issue replicates both on prod (cloud) and test (cloud). But not locally. So a nice 30 minute deployment pipeline run to test if your fix worked, since we are firewalled from direct DB connections from local dev machines, even for test instances.
    - john_the_writer 3y ago

lmm 3y ago

Somewhere Edward Kmett has a great post about how he realised he was just writing buggy code that would have to be thrown again away and away, and that was the point where he switched to writing Haskell libraries that were perfect and could live forever.

raincole 3y ago

Bug-free is more about how narrow the spec is. Can your GUI app works on a Windows 95 with Polish as the system langauge while using a Chinese input method, and the user holding Alt all the time? Probably not. But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case?

lelanthran 3y ago
> But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case? I don't even think it is necessary to ask that question. The only question that should be asked for something like this is "How do we handle all unsupported use-cases?" Because then it becomes simpler, when an edge-case causes the software to freeze, to detect for that edge-case and hand it off to the "not supported" handler. In the best case scenario, we simply detect whether the use-case is supported and then either proceed or hand control to the not-supported-handler. In the worst case scenario, when the bug report comes in, we don't even bother trying to reproduce it, we just add a general check for it and move on to the not-supported-handler. In this particular case, the detection can do any one of the following: 1. Check for english, and if not, display "unsupported language". 2. Check that input language and system language match, or display unsupported". 3. Check that the OS is supported, display "unsupported OS" if not. 4. Check that the input is valid (i.e. no special codes, whether by holding down halt or otherwise), or display "unsupported input". Whether the spec is narrow or wide, the developer needs to do the work to ensure that the user is running within spec. Not checking results in more "bugs" that are, as you said, use-cases which shouldn't be supported anyway.
- pixl97 3y ago
  >"How do we handle all unsupported use-cases?" Until you find out that your operating system handles 95% of unsupported cases in one way, then uses a hidden API to deal with the weirdness of other languages and the unsupported case isn't detected in that last 5% of languages. Of course that never came up in testing because who uses a hebrew/japanese combination and now the error message being returned by your application has nothing to do with the actual problem. Your worst case scenario is just the common edge case bug handling that support/QA/dev's handle every day.

63 3y ago

I think about this pretty often from the opposite perspective. As a frequent user of software, I can't get over how much it all sucks. Nearly every nontrivial piece of software I've ever used has had annoying and frustrating bugs and it feels to me like that's only getting worse. I agree that there's no correct software and I think the software engineering discipline needs to be blamed more for it. I don't think we deserve these salaries just to churn out broken code. I love programming but you can bet that the second there's an AI that can write perfect code, I'm advocating for it to replace us all because I'm tired of broken software.

pvdoom 3y ago
Well, there is a massive force that acts directly against not doing broken code - people(read managers and stakeholders) don't want to wait, they want the value for their money now, and from their perspective a certain degree of brokenness is fine
- pixl97 3y ago
  As long as it works "well enough" a broken product that ships now is better than a perfect product that never ships.
  - pvdoom 3y ago
    Yes, but also this very easily turns into shipping absolute crap, that in itself can cause a good concept to flop. There is a balance to be had, and at least some decent minimum requirements on what is good enough to ship. You neither want to overdosing, nor ship the first draft that sort of kinda works, and that second thing happens way too often.
ozim 3y ago
What software are you using and what were last 10 frustrating bugs you encountered? I find it fascinating because my use of software seems bug free in last 5-10 years. It is hard for me to run nowadays into a frustrating bug. When I was in high school there were just loads of bugs and everything seemed broken it was 2005ish and before. Windows was crashing now and again, had to reinstall frequently, software was crashing taking my work with it so I still have compulsive ctrl-s tick.

PH95VuimJjqBqy 3y ago

The goal isn't to produce perfect code, the goal is to evolve to perfect code. This gets missed by so many developers, once you change your mindset on this, you'll find you write better software. One of the questions to ask when writing code is "how long will it take to discover if this goes wrong?". Make it quick to find, let someone else in the future deal with the imperfections. I'm not saying don't try for perfect code, I'm saying not having written perfect code isn't a problem and it isn't a failing. code evolves to be stable, it is not born that way.