4 ms·

Unit Tests are not the one and only metrics for software quality. Believe it or not, before unit tests were coined, we managed to build reliable software too. A

Unit Tests are not the one and only metrics for software quality. Believe it or not, before unit tests were coined, we managed to build reliable software too. Actually a lot of the internet was actually built that way. But your assumption is very interesting, because it states a very common misconception of quality (whatever that means, reliability, maintainability, resilience, etc): * "Unit tests imply reliable software". Well, it does not, you'd need reliable unit tests for that, and from what I've seen in the industry, not every unit test out in the wild increases reliability. * "Without unit tests, you can't have quality software". That is just not true either. First, not all tests are unit tests, end-to-end (integration/functional/whatever) test are extremely useful and raises the quality too. Even without any automated test, the quality of documentation, contract programming, manual testing, etc also help a lot. Also, note that apart from testing, a lot of different practices contribute to reliability. Separation of concerns, the language level of abstraction, the overall experience and involvements of the developers, and many others.

jeremiep 10y ago
I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. To me, keeping code simple and easy to reason about is what yields reliable software. If you can't wrap your head around something in the first place then tests are only going to give you the illusion of reliability. Its as Rich Hickey put it: "What does every bug have in common? They all passed the type checker and the tests!"
- Cacti 10y ago
  As the saying goes, crap in, crap out. It's just as easy to write crappy unit tests as it is crappy code.
  - tmm 10y ago
    Or, as W. E. Deming wrote: "You cannot inspect quality into a product."
  - finishingmove 10y ago
    And it's extremely hard to write unit tests for crappy code.
    - Cacti 10y ago
      Extremely hard to write _good_ unit tests for crappy code.
  - danudey 10y ago
    After three years of working on some software (basically some fancy shell scripting but in Python), when the project had grown dramatically beyond its original scope through a host of hacks and bolted-on features, I remembered that the software had unit tests and ran them. Surprisingly, all the unit tests passed, and my first thought when I saw that was "Man, I bet these unit tests are awful."
- mathgeek 10y ago
  > I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I'm inclined to think this could be generalized to those who are most obsessed about any specific practice.
  - thenewregiment 10y ago
    Absolutely. The majority of the programming world is obviously dumb. You are the true master.
  - ams6110 10y ago
    A very non-PC joke from George Carlin springs to mind...
- pmarreck 10y ago
  > I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I don't think you can generalize this, neither subjectively (my shipping code quality has gone way up since I switched to TDD) nor empirically (evidence seems to indicate that you can achieve up to a 90% production bug reduction with a 15-35% upfront extra time cost doing TDD, which most would consider "worth it"). Secondly, this doesn't mean a very good programmer on a team doesn't have to write tests, if only to prevent others from breaking the behavior expectations of his code down the line. Thirdly, tests serve to validate that behavior if you yourself ever have to go back to the code to change or refactor it, so unless you are SO good of a programmer that you have perfect memory of the mental models of all your past code (which would put you in the extreme minority of all programmers), they will still come in handy.
  - jeremiep 10y ago
    Bad programmers are going to make a mess of things no matter how many tests you have. More often than not I see tests as needlessly solidifying the architecture prematurely. More often than not I see TDD yielding horrible, terrible software architectures and at that point you do need tests to maintain the resulting mess. TDD somehow assumes emergent architectures and I know from experience this is the worst way to architect something. NPM for example is full of well-tested libraries with poor architecture and bad usability (could be why everything is reinvented every 6 months) but I wouldn't call that a success story. I'm willing to bet the bug reduction from the extra time upfront doesn't come from doing TDD but actually thinking about the requirements and how they fit the larger picture. I really like the following story to illustrate this point: http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-so...
    - pmarreck 10y ago
      That blog post simply shows that Ron Jeffries failed to understand the core problem of "how to solve Sudoku puzzles" (or lost interest before he succeeded, which explains why he spent so much time on the data representation aka "bike shedding" or "yak shaving") and is no indictment of TDD, which is not a magic elixir that allows you to "organically" solve every possible problem. > horrible, terrible software architectures 1) Need an example. 2) There is no evidence that the architecture would have not been even MORE horrible AND terrible without the TDD involvement > needlessly solidifying the architecture prematurely As all code (whether "test code" or "tested code") is wont to do. Perhaps the fallacy here is considering test code as a separate, "optional" entity in your codebase instead of as an integrated proof of it working as advertised. > willing to bet the bug reduction ... comes from thinking about the requirements Still not an argument against TDD. If anything, that's an argument FOR it. The difference being at the end of the day, you have a working proof of the satisfaction of your requirements. Whiteboarding and TDD are not mutually-exclusive. I don't think that TDD at all implies "not thinking about the problem" nor does using it turn a crappy programmer (who would tend to choose terrible designs over better ones) into a good one. I think you are still constrained by the skill of the programmer no matter whether you use TDD or not. As TDD is just human-produced code, like all code. NPM could have had lots of fresh out of college monkeys work on it for all I know. It certainly wouldn't surprise me. You're right that TDD won't fix being an inexperienced programmer, but that's not an anti-TDD argument, that's an anti-inexperienced-developer argument. Lastly, you failed to address the other arguments I made in favor of using TDD (note: there's some conflation here between "unit testing" in general and TDD specifically unfortunately)
- entee 10y ago
  I think unit tests are a great tool to motivate code that is simple and easy to reason about. After all, a good unit test is itself simple and easy to reason about. It also forces you to think about what is the simplest unit of software for a given task, helping design the software it is testing. Also, I've definitely had code I thought was well tested and good to go, but when I rigorously went back and wrote unit tests, I found subtle bugs I wouldn't otherwise have known to fix. That said, yeah it's not all it takes to get things right. Dogma is bad, but unit tests are an essential part of the toolkit for ensuring code quality.
  - kedean 10y ago
    Yeah, i've found that my heavily unit tested code is often my best code, simply because designing it with that in mind yields the simplest, smallest units. If I know I'm gonna need to write a unit test later, I'm much more inclined to split a long function out into more sensible small ones, and I'm not going to try to combine two different behaviors (because that's hell to test).
teej 10y ago
Could to into more detail about what techniques NASA specifically used to achieve quality software? I'm honestly very interested. I feel like you didn't answer the spirit of the question "How did NASA build highly reliable software" while pigeon holeing on "without unit tests".
- Cacti 10y ago
  Their hardware was essentially fixed, well defined, and limited in scope. They reviewed every single piece of code many, many times. They were draconian about memory handling, loops, preprocessor directives, and recursion. All functions had to check all return types from other functions. No more than one level of pointer dereferencing. All code bodies had to fit on a piece of paper. /edit should add, they used their tools thoroughly: compilers were run on max warning levels and absolutely no warnings were accepted, ever. They also used several static analysis tools on the code (under-appreciated these days!).
  - yardie 10y ago
    I'd also add they had excellent, mature coders. None of this crunch time bullshit, though I'm sure it happened. I've been on one of those binges. If another coder hadn't seen my errors, due to diminishing sleep, I'd probably keep banging my head against the wall. Just compounding the situation.
    - Jtsummers 10y ago
      Anecdotal generalization: I've seen better code from the 40-hour-a-week guys than the ones that do 80 hours of overtime each week. That doesn't mean the former finish first, they usually don't. But their code tends to be more thoughtfully constructed. They have a vested interest in not spending their time in the office, and that means minimizing debugging time along with coding time. When you're in a hot field with lots of competition, maybe those sprints make sense. But in the field of NASA-type systems, there may be a deadline, but it's rarely urgent. This gives the developers much more time to step back, breathe, and think.
    - 10y ago
iweinfuld 10y ago
Another assumption there is: Nasa had reliable software. From what stories I heard, I think that may not be true.

jeremiep 10y ago

I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. To me, keeping code simple and easy to reason about is what yields reliable software. If you can't wrap your head around something in the first place then tests are only going to give you the illusion of reliability. Its as Rich Hickey put it: "What does every bug have in common? They all passed the type checker and the tests!"

Cacti 10y ago
As the saying goes, crap in, crap out. It's just as easy to write crappy unit tests as it is crappy code.
- tmm 10y ago
  Or, as W. E. Deming wrote: "You cannot inspect quality into a product."
- finishingmove 10y ago
  And it's extremely hard to write unit tests for crappy code.
  - Cacti 10y ago
    Extremely hard to write _good_ unit tests for crappy code.
- danudey 10y ago
  After three years of working on some software (basically some fancy shell scripting but in Python), when the project had grown dramatically beyond its original scope through a host of hacks and bolted-on features, I remembered that the software had unit tests and ran them. Surprisingly, all the unit tests passed, and my first thought when I saw that was "Man, I bet these unit tests are awful."
mathgeek 10y ago
> I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I'm inclined to think this could be generalized to those who are most obsessed about any specific practice.
- thenewregiment 10y ago
  Absolutely. The majority of the programming world is obviously dumb. You are the true master.
- ams6110 10y ago
  A very non-PC joke from George Carlin springs to mind...
pmarreck 10y ago
> I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I don't think you can generalize this, neither subjectively (my shipping code quality has gone way up since I switched to TDD) nor empirically (evidence seems to indicate that you can achieve up to a 90% production bug reduction with a 15-35% upfront extra time cost doing TDD, which most would consider "worth it"). Secondly, this doesn't mean a very good programmer on a team doesn't have to write tests, if only to prevent others from breaking the behavior expectations of his code down the line. Thirdly, tests serve to validate that behavior if you yourself ever have to go back to the code to change or refactor it, so unless you are SO good of a programmer that you have perfect memory of the mental models of all your past code (which would put you in the extreme minority of all programmers), they will still come in handy.
- jeremiep 10y ago
  Bad programmers are going to make a mess of things no matter how many tests you have. More often than not I see tests as needlessly solidifying the architecture prematurely. More often than not I see TDD yielding horrible, terrible software architectures and at that point you do need tests to maintain the resulting mess. TDD somehow assumes emergent architectures and I know from experience this is the worst way to architect something. NPM for example is full of well-tested libraries with poor architecture and bad usability (could be why everything is reinvented every 6 months) but I wouldn't call that a success story. I'm willing to bet the bug reduction from the extra time upfront doesn't come from doing TDD but actually thinking about the requirements and how they fit the larger picture. I really like the following story to illustrate this point: http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-so...
  - pmarreck 10y ago
    That blog post simply shows that Ron Jeffries failed to understand the core problem of "how to solve Sudoku puzzles" (or lost interest before he succeeded, which explains why he spent so much time on the data representation aka "bike shedding" or "yak shaving") and is no indictment of TDD, which is not a magic elixir that allows you to "organically" solve every possible problem. > horrible, terrible software architectures 1) Need an example. 2) There is no evidence that the architecture would have not been even MORE horrible AND terrible without the TDD involvement > needlessly solidifying the architecture prematurely As all code (whether "test code" or "tested code") is wont to do. Perhaps the fallacy here is considering test code as a separate, "optional" entity in your codebase instead of as an integrated proof of it working as advertised. > willing to bet the bug reduction ... comes from thinking about the requirements Still not an argument against TDD. If anything, that's an argument FOR it. The difference being at the end of the day, you have a working proof of the satisfaction of your requirements. Whiteboarding and TDD are not mutually-exclusive. I don't think that TDD at all implies "not thinking about the problem" nor does using it turn a crappy programmer (who would tend to choose terrible designs over better ones) into a good one. I think you are still constrained by the skill of the programmer no matter whether you use TDD or not. As TDD is just human-produced code, like all code. NPM could have had lots of fresh out of college monkeys work on it for all I know. It certainly wouldn't surprise me. You're right that TDD won't fix being an inexperienced programmer, but that's not an anti-TDD argument, that's an anti-inexperienced-developer argument. Lastly, you failed to address the other arguments I made in favor of using TDD (note: there's some conflation here between "unit testing" in general and TDD specifically unfortunately)
entee 10y ago
I think unit tests are a great tool to motivate code that is simple and easy to reason about. After all, a good unit test is itself simple and easy to reason about. It also forces you to think about what is the simplest unit of software for a given task, helping design the software it is testing. Also, I've definitely had code I thought was well tested and good to go, but when I rigorously went back and wrote unit tests, I found subtle bugs I wouldn't otherwise have known to fix. That said, yeah it's not all it takes to get things right. Dogma is bad, but unit tests are an essential part of the toolkit for ensuring code quality.
- kedean 10y ago
  Yeah, i've found that my heavily unit tested code is often my best code, simply because designing it with that in mind yields the simplest, smallest units. If I know I'm gonna need to write a unit test later, I'm much more inclined to split a long function out into more sensible small ones, and I'm not going to try to combine two different behaviors (because that's hell to test).

teej 10y ago

Could to into more detail about what techniques NASA specifically used to achieve quality software? I'm honestly very interested. I feel like you didn't answer the spirit of the question "How did NASA build highly reliable software" while pigeon holeing on "without unit tests".

Cacti 10y ago
Their hardware was essentially fixed, well defined, and limited in scope. They reviewed every single piece of code many, many times. They were draconian about memory handling, loops, preprocessor directives, and recursion. All functions had to check all return types from other functions. No more than one level of pointer dereferencing. All code bodies had to fit on a piece of paper. /edit should add, they used their tools thoroughly: compilers were run on max warning levels and absolutely no warnings were accepted, ever. They also used several static analysis tools on the code (under-appreciated these days!).
- yardie 10y ago
  I'd also add they had excellent, mature coders. None of this crunch time bullshit, though I'm sure it happened. I've been on one of those binges. If another coder hadn't seen my errors, due to diminishing sleep, I'd probably keep banging my head against the wall. Just compounding the situation.
  - Jtsummers 10y ago
    Anecdotal generalization: I've seen better code from the 40-hour-a-week guys than the ones that do 80 hours of overtime each week. That doesn't mean the former finish first, they usually don't. But their code tends to be more thoughtfully constructed. They have a vested interest in not spending their time in the office, and that means minimizing debugging time along with coding time. When you're in a hot field with lots of competition, maybe those sprints make sense. But in the field of NASA-type systems, there may be a deadline, but it's rarely urgent. This gives the developers much more time to step back, breathe, and think.
  - 10y ago

iweinfuld 10y ago

Another assumption there is: Nasa had reliable software. From what stories I heard, I think that may not be true.