4 ms·

A lot of the bugs in our code are completely avoidable, but people get in the mindset of, "I need to move fast, bugs don't matter!" Even if you don't have QA,

A lot of the bugs in our code are completely avoidable, but people get in the mindset of, "I need to move fast, bugs don't matter!" Even if you don't have QA, when you write a bug, at least ask yourself, "what could I have done differently to avoid that bug in the future?" In some cases, it's as simple as, "put repeated code into a function so it doesn't get written twice." That will cut your chances of getting a typo in half.

ArkyBeagle 11y ago
So , really - you actually see typo bugs in the wild? I haven't seen one of those for 20 years. I do see lots of cases where people didn't test it or used the wrong mechanism. I have to go slowly because somebody already went fast and broke it. And a friend once told me "LZW can compress code faster than you can." :) Which does not go to the value of orthogonality of purpose in source code, but I enjoyed the irony of the comment very much.
- collyw 11y ago
  Probably happens more frequently than you think in dynamic languages. Even in compiled languages I imagine its reasonably common to compare something to a hard coded string that could easily be mistyped.
  - ArkyBeagle 11y ago
    I wasn't thinking of dynamic languages at all. I'd agree.
- chipsy 11y ago
  Math-heavy code tends to involve a lot of very similar algorithms, leading to a copy-paste-rename situation that isn't really helped by using a function. As such it's incredibly common to end up with bugs from assigning to "x, y, y" and not "x, y, z" etc. Sometimes a clever compiler will warn you that you have done something odd, other times you'll be left to discover the runtime error.
  - ArkyBeagle 11y ago
    Yeah, there's that. I've printed out code like that and colored different variables with different color highlighters to deal with it.
- ktRolster 11y ago
  Here's one more recent than 20 years: http://www.theregister.co.uk/2009/07/30/typo_caused_massive_ms_bug/ http://www.theregister.co.uk/2009/07/30/typo_caused_massive_... You're right though, with care and skill, typos really shouldn't be an issue
sbov 11y ago
This seems like a really uncommon case. The vast majority of bugs I've ran across is an incorrect mental model of how something works: your system, some library, or an external system you're interfacing with. Aside from building a more understandable system (whatever that really means/entails), from my experience, the best way to counteract this is to, while writing code, always ask: "What if my understanding is wrong? What if someone else's understanding is wrong? What can I do to make the system fail in the loudest way possible if someone's understanding is wrong?"
- ArkyBeagle 11y ago
  Generally, have the interface to the module under utilization be as simple as heck. As an example, I have a system for which almost all state is represented as XML/JSON/CSV text when it is outside the system. Inside the system it's tables of tuples with a master table of names cross references. Each "object" has an instantiator, a "process" callback and ... that's it. It's all done in a timer-based polling cycle ( after a select()/epoll() loop ). Each "object" owns a timer of its own that specifies the minimum poll time. There basically are no parameters after object creation, so you can't get parameters wrong. You have to send XML/JSON/CSV to it to change state. XML/JSON/CSV for initial configuration is controlled and shipped with the executable. For all settable state in the tables, there is a formal validation method and a controlled script to test them. The the client-writers, I provide correct scripts for each use case that they can then steal or modify. This way, I just don't have problems.
- ktRolster 11y ago
  That goes with what Glenford Meyers said, that all bugs are transcription bugs, either from the requirements to the programmer, or from the programmers head to his fingers, or.....

ArkyBeagle 11y ago

So , really - you actually see typo bugs in the wild? I haven't seen one of those for 20 years. I do see lots of cases where people didn't test it or used the wrong mechanism. I have to go slowly because somebody already went fast and broke it. And a friend once told me "LZW can compress code faster than you can." :) Which does not go to the value of orthogonality of purpose in source code, but I enjoyed the irony of the comment very much.

collyw 11y ago
Probably happens more frequently than you think in dynamic languages. Even in compiled languages I imagine its reasonably common to compare something to a hard coded string that could easily be mistyped.
- ArkyBeagle 11y ago
  I wasn't thinking of dynamic languages at all. I'd agree.
chipsy 11y ago
Math-heavy code tends to involve a lot of very similar algorithms, leading to a copy-paste-rename situation that isn't really helped by using a function. As such it's incredibly common to end up with bugs from assigning to "x, y, y" and not "x, y, z" etc. Sometimes a clever compiler will warn you that you have done something odd, other times you'll be left to discover the runtime error.
- ArkyBeagle 11y ago
  Yeah, there's that. I've printed out code like that and colored different variables with different color highlighters to deal with it.
ktRolster 11y ago
Here's one more recent than 20 years: http://www.theregister.co.uk/2009/07/30/typo_caused_massive_ms_bug/ http://www.theregister.co.uk/2009/07/30/typo_caused_massive_... You're right though, with care and skill, typos really shouldn't be an issue

sbov 11y ago

This seems like a really uncommon case. The vast majority of bugs I've ran across is an incorrect mental model of how something works: your system, some library, or an external system you're interfacing with. Aside from building a more understandable system (whatever that really means/entails), from my experience, the best way to counteract this is to, while writing code, always ask: "What if my understanding is wrong? What if someone else's understanding is wrong? What can I do to make the system fail in the loudest way possible if someone's understanding is wrong?"

ArkyBeagle 11y ago
Generally, have the interface to the module under utilization be as simple as heck. As an example, I have a system for which almost all state is represented as XML/JSON/CSV text when it is outside the system. Inside the system it's tables of tuples with a master table of names cross references. Each "object" has an instantiator, a "process" callback and ... that's it. It's all done in a timer-based polling cycle ( after a select()/epoll() loop ). Each "object" owns a timer of its own that specifies the minimum poll time. There basically are no parameters after object creation, so you can't get parameters wrong. You have to send XML/JSON/CSV to it to change state. XML/JSON/CSV for initial configuration is controlled and shipped with the executable. For all settable state in the tables, there is a formal validation method and a controlled script to test them. The the client-writers, I provide correct scripts for each use case that they can then steal or modify. This way, I just don't have problems.
ktRolster 11y ago
That goes with what Glenford Meyers said, that all bugs are transcription bugs, either from the requirements to the programmer, or from the programmers head to his fingers, or.....