3 ms·

I am certainly not a great programmer, but I'll add a concept to this list: you avoid bugs by not writing code. Ruthlessly focus on the minimum viable amount o

I am certainly not a great programmer, but I'll add a concept to this list: you avoid bugs by not writing code. Ruthlessly focus on the minimum viable amount of code for a given problem, or if a problem can be avoided entirely. Minimalism in code and software design is a beautiful thing, but it doesn't get a lot of press because "the new hotness", "grow or die", "we have to do something", and so on.

pizlonator 10y ago
Word. I learned this when I dabbled in real time systems. Those dudes can crank out some hella reliable code. At first I thought it was despite the cumbersome dev processes that old school RT software uses. Now I realize it is because the process imposes a high cost on each line of code. So, there's less code. Less code = fewer bugs.
blazespin 10y ago
Yeah, I know a lot of programmers who subscribe to this theory. Frequently programmers I prefer not to work with, I'm afraid. I prefer working with the programmers who write a lot of code (often with bugs) and then refactor into something minimal. The advantage is that they produce something early that we can get feedback on and we can spiral into the right solution, both architecture / feature wise.
- crpatino 10y ago
  I guess everyone is entitled to their preferences, as long as they don't try to force them into anothers. The problem with the "code a lot, then refactor" approach is that it takes a lot of different skills to actually pull off. Some of the pitfalls I have seen are: 1. You need an unusual amount of perseverance, or the feedback of very knowledgeable, outspoken and candid coworkers to actually perform an acceptable refactor, instead of the usual brushing of dirt under a thin (leaky) abstraction. Some of my best work I have done while challenged by colleagues that did not allow me to get away with the "good enough" version I initially wanted to settle with. 2. You need to command an amount of social capital that is not normally granted to mere programmers in order to let the higher-ups that: "Yes, it seems to be working, but no, it is not production ready yet. Do I need to remind you, again, that you agreed to create a throw-away prototype from the very beginning?" In my experience, experimental code - no matter how rough - gets promoted to officialdom status the very minute it's pushed into your source control system. 3. Even if you can navigate #1 and #2 successfully, you still need a lot of forethought in order to design a robust API that will allow your coworkers to interact with your module without being disrupted by your ongoing refactoring. 3.1 As a corollary to the previous one, the effort to communicate the robust API from #3 grows super-lineraly to the size of your team. Not only the probability of someone being left out of the loop grows with N, but also the probability of some idiot^H^H^H^H^H misguided person deciding to ignore all warnings and rely on some implementation detail to accomplish some short term milestone. 4. Finally, you need to actually catch the bugs in order to justify all of the above. This is not an actual skill that need to have in order to do that, but it means that any problem that you might have gets amplified by any defect or omission you may have in your testing strategy.
  - Bromskloss 10y ago
    > You need an unusual amount of perseverance, or the feedback of very knowledgeable, outspoken and candid coworkers to actually perform an acceptable refactor, instead of the usual brushing of dirt under a thin (leaky) abstraction. Refactoring is the most fun part! It's lovely when things become tidy, straight, and clean.
    - ricksplat 10y ago
      > tidy, straight, and clean and new bugs get introduced into erstwhile fully validated code ;-)
- ricksplat 10y ago
  It's horses for courses really. It all comes down to the cost of an escaped defect: Impact of failure; costs to rectify vs costs of writing bug free code. If for instance you're writing code for a vertically integrated application that you manage yourself you can fix it any time with little cost then simply "move fast and break things" makes sense. If you're shipping software where usage and maintenance is out of your control you should be a little more circumspect. If your code does something critical like manages e.g. a space shuttle [0] then there should be a significant $/£/€ tag attached to failure such that justifying an overbearing process is a no brainer. [0] http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff
z3t4 10y ago
How to avoid bugs: 1. Do not write *any* code (can't argue with that) 2. Write "good" code 3. Insert paradigm here (like TDD, etc) Be careful with "Ruthlessly focus on the minimum viable amount of code for a given problem". In my experience it will lead to "hacks" upon hacks, until the code-base gets unmanageable.
yitchelle 10y ago
This is the one advice I give my team every SINGLE day. I get them to spend time upfront to consider if it is necessary for the code. If you don't need it, don't write it. I work in embedded and the more code there is in there, the more chance a bug will happen. With embedded, we are not just talking about pure software bugs, we are talking about hardware bugs that is root caused to software functions. Sometimes easy to find, but also difficult to find.

pizlonator 10y ago

Word. I learned this when I dabbled in real time systems. Those dudes can crank out some hella reliable code. At first I thought it was despite the cumbersome dev processes that old school RT software uses. Now I realize it is because the process imposes a high cost on each line of code. So, there's less code. Less code = fewer bugs.

blazespin 10y ago

Yeah, I know a lot of programmers who subscribe to this theory. Frequently programmers I prefer not to work with, I'm afraid. I prefer working with the programmers who write a lot of code (often with bugs) and then refactor into something minimal. The advantage is that they produce something early that we can get feedback on and we can spiral into the right solution, both architecture / feature wise.

crpatino 10y ago
I guess everyone is entitled to their preferences, as long as they don't try to force them into anothers. The problem with the "code a lot, then refactor" approach is that it takes a lot of different skills to actually pull off. Some of the pitfalls I have seen are: 1. You need an unusual amount of perseverance, or the feedback of very knowledgeable, outspoken and candid coworkers to actually perform an acceptable refactor, instead of the usual brushing of dirt under a thin (leaky) abstraction. Some of my best work I have done while challenged by colleagues that did not allow me to get away with the "good enough" version I initially wanted to settle with. 2. You need to command an amount of social capital that is not normally granted to mere programmers in order to let the higher-ups that: "Yes, it seems to be working, but no, it is not production ready yet. Do I need to remind you, again, that you agreed to create a throw-away prototype from the very beginning?" In my experience, experimental code - no matter how rough - gets promoted to officialdom status the very minute it's pushed into your source control system. 3. Even if you can navigate #1 and #2 successfully, you still need a lot of forethought in order to design a robust API that will allow your coworkers to interact with your module without being disrupted by your ongoing refactoring. 3.1 As a corollary to the previous one, the effort to communicate the robust API from #3 grows super-lineraly to the size of your team. Not only the probability of someone being left out of the loop grows with N, but also the probability of some idiot^H^H^H^H^H misguided person deciding to ignore all warnings and rely on some implementation detail to accomplish some short term milestone. 4. Finally, you need to actually catch the bugs in order to justify all of the above. This is not an actual skill that need to have in order to do that, but it means that any problem that you might have gets amplified by any defect or omission you may have in your testing strategy.
- Bromskloss 10y ago
  > You need an unusual amount of perseverance, or the feedback of very knowledgeable, outspoken and candid coworkers to actually perform an acceptable refactor, instead of the usual brushing of dirt under a thin (leaky) abstraction. Refactoring is the most fun part! It's lovely when things become tidy, straight, and clean.
  - ricksplat 10y ago
    > tidy, straight, and clean and new bugs get introduced into erstwhile fully validated code ;-)
ricksplat 10y ago
It's horses for courses really. It all comes down to the cost of an escaped defect: Impact of failure; costs to rectify vs costs of writing bug free code. If for instance you're writing code for a vertically integrated application that you manage yourself you can fix it any time with little cost then simply "move fast and break things" makes sense. If you're shipping software where usage and maintenance is out of your control you should be a little more circumspect. If your code does something critical like manages e.g. a space shuttle [0] then there should be a significant $/£/€ tag attached to failure such that justifying an overbearing process is a no brainer. [0] http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff

z3t4 10y ago

How to avoid bugs: 1. Do not write *any* code (can't argue with that) 2. Write "good" code 3. Insert paradigm here (like TDD, etc) Be careful with "Ruthlessly focus on the minimum viable amount of code for a given problem". In my experience it will lead to "hacks" upon hacks, until the code-base gets unmanageable.

yitchelle 10y ago

This is the one advice I give my team every SINGLE day. I get them to spend time upfront to consider if it is necessary for the code. If you don't need it, don't write it. I work in embedded and the more code there is in there, the more chance a bug will happen. With embedded, we are not just talking about pure software bugs, we are talking about hardware bugs that is root caused to software functions. Sometimes easy to find, but also difficult to find.