"You keep saying this as if you believe that writing unit tests automatically means you've written good code"
Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!
I'd happily believe that someone who writes good code can also write good unit tests.
I'd also strongly assert the negative of that. Someone who writes bad code cannot possibly write good unit tests, because unit tests are code.
Everything else you say I agree with 110%. Good names for code entities: yes, indeed. Taking some time up front and thinking about the design and how it will fit together... yes, a thousand times yes.
However, the last bit about it taking longer to do this than just cranking something out I (and I think the person to whom you are replying) would disagree with except in the most trivial cases.
If what you are doing can be done by banging out a perl one-liner, by all means do that and move on. Except that of coruse if you ever need to debug it or maintain it there is a higher cost involved. For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out.
Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!
Well, idiomatically, the second sentence is a kind of restatement of the first. My comment was really a reply to all nikster's similar comments in this page; he's talking about unit tests, and those he's talking to are mentioning good code, so it seems as though he believes that good code is essentially the same as "have unit tests", which is what I took issue with. :)
For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out.
I actually don't disagree with this at all. It's just that I don't think the costs will necessarily be in hours spent, though sometimes they will be. Sometimes the cost will be that you have to find someone at least as smart as the original coder, and that might be hard. It might be so hard that hiring someone to completely rewrite the system from scratch might be cheaper.
So, I'm not saying that people shouldn't take the time to write good code. I'm saying that it's possible to write working code at the speed of typing for some people on some projects, and this can be kept up for long enough for the savings to completely outweigh the other costs if the number of bugs is small enough. I wouldn't recommend depending on this being possible for a given team and project, but I've seen it done -- I've done it myself. The result wasn't what I'd call good code, but it worked and it was done in time to be sold for enough to keep the wolf from the door; if I'd spent half my coding time writing tests on that one, I would simply have failed to deliver.
Comments
"You keep saying this as if you believe that writing unit tests automatically means you've written good code"
Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!
I'd happily believe that someone who writes good code can also write good unit tests.
I'd also strongly assert the negative of that. Someone who writes bad code cannot possibly write good unit tests, because unit tests are code.
Everything else you say I agree with 110%. Good names for code entities: yes, indeed. Taking some time up front and thinking about the design and how it will fit together... yes, a thousand times yes.
However, the last bit about it taking longer to do this than just cranking something out I (and I think the person to whom you are replying) would disagree with except in the most trivial cases.
If what you are doing can be done by banging out a perl one-liner, by all means do that and move on. Except that of coruse if you ever need to debug it or maintain it there is a higher cost involved. For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out.
Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!
Well, idiomatically, the second sentence is a kind of restatement of the first. My comment was really a reply to all nikster's similar comments in this page; he's talking about unit tests, and those he's talking to are mentioning good code, so it seems as though he believes that good code is essentially the same as "have unit tests", which is what I took issue with. :)
For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out.
I actually don't disagree with this at all. It's just that I don't think the costs will necessarily be in hours spent, though sometimes they will be. Sometimes the cost will be that you have to find someone at least as smart as the original coder, and that might be hard. It might be so hard that hiring someone to completely rewrite the system from scratch might be cheaper.
So, I'm not saying that people shouldn't take the time to write good code. I'm saying that it's possible to write working code at the speed of typing for some people on some projects, and this can be kept up for long enough for the savings to completely outweigh the other costs if the number of bugs is small enough. I wouldn't recommend depending on this being possible for a given team and project, but I've seen it done -- I've done it myself. The result wasn't what I'd call good code, but it worked and it was done in time to be sold for enough to keep the wolf from the door; if I'd spent half my coding time writing tests on that one, I would simply have failed to deliver.