4 ms·

You know, it is a great book and I love Jamie's interview and the "duct tape" style was used well at Netscape, but just because the guy doesn't writing unit tes

by tdavis 17y ago

You know, it is a great book and I love Jamie's interview and the "duct tape" style was used well at Netscape, but just because the guy doesn't writing unit tests or use higher-level abstractions doesn't automatically make him better than other types. Some of the smartest programmers I've met have been religious about TDD and strict formatting and commenting and as a result maintain and work on some incredibly large and complex systems. Did those systems start out that way? Maybe not, but after a few years and a couple rewrites I'm sure they came to the same conclusion that most programmers do when they work on things for a long time: "I wish I could go back and write some tests / automate some stuff / add better debugging, etc." I know I always feel that way. I do now, after about a year and a half of hacking together our site. I'd kill for a decent test suite and fully-automated deployment. Kill! Both styles of programming have a purpose. Maybe we'd like to avoid multi-threaded architectures, but it isn't always possible. When you have 6 weeks to launch, maybe unit tests aren't necessary, but eventually not having them will start doing more harm than good. The more I read the writings of celebrity programmers / entrepreneurs, the more I come to realize that most of what they write reads like an attempt to justify their way of thinking as being The Right Way. Why can't we all just agree there is more than one way to skin a cat and each probably has an applicable use case or two?

Tichy 17y ago
"I'd kill for a decent test suite and fully-automated deployment. Kill!" Then why don't you write one? I suspect you don't have the time - well back then when you created the system, you did not have the time either. So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.
- SapphireSun 17y ago
  That's not true. Just because he never gets the chance to doesn't mean that if he had it, it wouldn't make him more efficient. If you're bailing out a ship, you might not have time to run and get a motorized pump, but you sure as hell would like one!
  - tjogin 17y ago
    So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were more necessary then.
    - azanar 17y ago
      So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were necessary at the time. Might have been better spent. Might have. Say that it was better spent is just begging the question. That he didn't get the pump can be blamed as much on poor risk mitigation as it can be on avoiding unnecessary expenses. Having a cavalier and dismissive attitude toward mitigating future risks can result in a demonstration of exactly how faulty one's prioritizations really were. Don't fall into the trap of assuming just because things were done out of assumed necessity, they were the right things to do.
      - Tichy 17y ago
        Fair point with the motor pump, but it seems to me that we end up on square one: it might have been better to get the pump in advance, or it might not have been better. It all depends. With the motor pump example it sounds like a no-brainer, but even there it depends. If you have a very small boat, heaving a motor pump on board might actually sink the ship. There are all sorts of risks, and it isn't obvious when it is worthwhile to get insurance and when it isn't. One risk is never launching.
        azanar 17y ago
        There are all sorts of risks, and it isn't obvious when it is worthwhile to get insurance and when it isn't. One risk is never launching. Right. I'm not saying become paralyzed due to the risks. And I'm not saying do dumb things that mitigate a risk with an even bigger risk. What I'm saying is don't assume your conclusions. Things that other people might argue are important might not seem that important to you, given whatever perspective you have at the time. It is possible part of the reason they argue for using a certain practice is because they, too, didn't see it as important until they got burned hard for their presumption. This is not to say they are important. It might be that people are just squawking to sell books or consulting hours or seats at a conference. But, to use a really dumb metaphor, if that many hens are squawking about the same thing, it might be time to look in the barn and see what all the noise is about.
- azanar 17y ago
  So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time. Another possibility is that it is important, possibly even more important than the other things they are working on, but isn't getting prioritized for other reasons. They've succeeded thus far with the way they have prioritized things, but that doesn't mean that they made all the right choices, it just means they made enough right choices to survive to this point. The future may prove tdavis painfully right in his concern about not having test cases. Another company that may not have made enough other choices correctly may be able to cling to having tests and deployment automated as the thing that saves them. I don't think you can draw any real correlation except that it might not be that important, and only time will tell.
- tdavis 17y ago
  On the topic of testing, it's only currently viable to write tests for bugs which occur in the future and that are properly caught (I recently caught one completely by accident because it wasn't caught by our alert system). Going back and trying to write test cases for everything I've written up to this point simply makes no sense; they should have been written before the code, from the start (or from a point that I knew the code wouldn't be re-written again). Automated deployment has been less of a priority because I don't really have to re-deploy that often (meaning spin up a new server). However, if/when I do need to, it will be automated. Even if I haven't written the scripts yet, I will do it before the new machine comes up. Back when the system was created I had never been a "TDDer" before and the tools that exist now did not exist or were not viable for production, especially in terms of automated deployment and dependency management. If I could go back and do it again (or just murder someone) I'd love to have good test coverage and automation tools. It isn't that it's not important, it's just that the ship has sailed on half of it and the other half is situation-dependent at this stage. In summary, it is THAT important. I will go as far to say that I think these two items in particular are more or less vital to the long-term viability of a software project. Anyone maintaining a large, aged project that contains no test coverage and no automated build / deploy tools has my deepest sympathies; it's like stacking an infinite house of cards.
  - mechanical_fish 17y ago
    Back when the system was created I had never been a "TDDer" before and the tools that exist now did not exist... Amen. I think a lot of the heated arguments about the value of testing arise from the fact that not everybody is using the same toolset. I'm sure unit testing in C is a major pain in the neck. (Can anybody link me to a document suggesting how to do it?) I know that unit testing in PHP is no picnic. But testing in Ruby is a joy, because the Ruby community has lavished attention on the subject over the last five years and the language, the tools, the idioms, and the culture are highly developed.
- akeefer 17y ago
  That's a bad conclusion to make: it's the classic tradeoff between importance and urgency. If you only ever do the urgent stuff, the hair-on-fire-has-to-be-done-yesterday stuff, you'll never make time to get to long-term strategic projects. The payoff for something like unit testing, automated deployment, and continuous integration are over the very, very long haul. If your cost/benefit analysis is always looking at 3- or 6-months out, it'll never seem like a win. So if you only ever do the urgent stuff and never anything strategic, 3 years later you'll realize that if you'd just sucked it up back at the start and done that stuff, even if meant putting off otherwise urgent features, you'd be further ahead than you are now, because it would have more than made up for the initial investment. So it's not that you don't do those things because they're not important, but rather because they're never urgent, and because most people's time horizons, especially in a startup, are fairly short.
  - Tichy 17y ago
    Still, in 3 years the company might already be bankrupt, and nobody would care about tests anymore. Bankrupt is maybe too extreme, but the particular code module you spent 3 months writing tests for might be replaced by some open source solution or just not being needed anymore. I kind of see your point, but I find it difficult to deduce a binding rule from all of this. Sometimes it is important to have tests, sometimes other things are more important. You still have to decide on an individual basis. Thing is, the TDD and technical debt evangelists are typically consultants. Consultants usually earn more money the longer a project takes, and their income is not tied to the yields of the project. Just something to take into consideration imo.
    - shiro 17y ago
      > Consultants usually earn more money the longer a project takes, and their income is not tied to the yields of the project. Well... that seems oversimplification. When I consult, I ask the price roughly based on the estimation of how much time I'm going to take, but ultimately it is the matter that how much value the client sees in the outcome. Note that the expected outcome and the price are agreed beforehand---if I bump into an unforeseen obstacle and take twice time as my estimation, I can't ask them twice price; basically the more I work, the less I make per hour. So (1) I have a very strong incentive to make sure my part works in time, and (2) There's less incentive to finish the work earlier than the initial estimation. Thus I tend to put effort to write tests and debugging aids within the time frame (or, in other words, I try to negotiate initial time frame including those tests). Certainly there's a different pressure on employees; they may adjust priorities and time frames more frequently. So, it is true that consultants make more money the longer the project takes, but the incentive is in making sure it won't take longer than expected, rather than making it take longer deliberately. (After all, if the consultant is doing ok, there are projects in waiting list so it's not much point to taking one project longer than necessary.)
- abalashov 17y ago
  it is not actually THAT important. Otherwise you would make the time. ... that's just a little presumptuous, with respect to the concrete facts and motivations involved...
  - Tichy 17y ago
    Didn't mean it that way, and why do you think so? How else to judge importance than by "people pay for it/make time for it"?
  - blasdel 17y ago
    It comes down to the fact that noone really has priorities, much less ranked ones -- there is only the priority, and it's whatever you're presently doing.
vsiva68 17y ago
My sentiments exactly. Joel's article is just unnecessarily long with very little real content. There are many different ways to develop - Some people like C++, some don't, some do TDD, some don't. You can never say this is the ONE true way to develop. Do what works for you, but just be aware of other points of view.

by tdavis 17y ago

Tichy 17y ago

"I'd kill for a decent test suite and fully-automated deployment. Kill!" Then why don't you write one? I suspect you don't have the time - well back then when you created the system, you did not have the time either. So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time.

SapphireSun 17y ago
That's not true. Just because he never gets the chance to doesn't mean that if he had it, it wouldn't make him more efficient. If you're bailing out a ship, you might not have time to run and get a motorized pump, but you sure as hell would like one!
- tjogin 17y ago
  So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were more necessary then.
  - azanar 17y ago
    So why didn't he get a motorized pump before the alarming need for it arose? Because, at the time, that money was better spent on other things that were necessary at the time. Might have been better spent. Might have. Say that it was better spent is just begging the question. That he didn't get the pump can be blamed as much on poor risk mitigation as it can be on avoiding unnecessary expenses. Having a cavalier and dismissive attitude toward mitigating future risks can result in a demonstration of exactly how faulty one's prioritizations really were. Don't fall into the trap of assuming just because things were done out of assumed necessity, they were the right things to do.
    - Tichy 17y ago
      Fair point with the motor pump, but it seems to me that we end up on square one: it might have been better to get the pump in advance, or it might not have been better. It all depends. With the motor pump example it sounds like a no-brainer, but even there it depends. If you have a very small boat, heaving a motor pump on board might actually sink the ship. There are all sorts of risks, and it isn't obvious when it is worthwhile to get insurance and when it isn't. One risk is never launching.
      - azanar 17y ago
        There are all sorts of risks, and it isn't obvious when it is worthwhile to get insurance and when it isn't. One risk is never launching. Right. I'm not saying become paralyzed due to the risks. And I'm not saying do dumb things that mitigate a risk with an even bigger risk. What I'm saying is don't assume your conclusions. Things that other people might argue are important might not seem that important to you, given whatever perspective you have at the time. It is possible part of the reason they argue for using a certain practice is because they, too, didn't see it as important until they got burned hard for their presumption. This is not to say they are important. It might be that people are just squawking to sell books or consulting hours or seats at a conference. But, to use a really dumb metaphor, if that many hens are squawking about the same thing, it might be time to look in the barn and see what all the noise is about.
azanar 17y ago
So the bottom line again seems to be: it is not actually THAT important. Otherwise you would make the time. Another possibility is that it is important, possibly even more important than the other things they are working on, but isn't getting prioritized for other reasons. They've succeeded thus far with the way they have prioritized things, but that doesn't mean that they made all the right choices, it just means they made enough right choices to survive to this point. The future may prove tdavis painfully right in his concern about not having test cases. Another company that may not have made enough other choices correctly may be able to cling to having tests and deployment automated as the thing that saves them. I don't think you can draw any real correlation except that it might not be that important, and only time will tell.
tdavis 17y ago
On the topic of testing, it's only currently viable to write tests for bugs which occur in the future and that are properly caught (I recently caught one completely by accident because it wasn't caught by our alert system). Going back and trying to write test cases for everything I've written up to this point simply makes no sense; they should have been written before the code, from the start (or from a point that I knew the code wouldn't be re-written again). Automated deployment has been less of a priority because I don't really have to re-deploy that often (meaning spin up a new server). However, if/when I do need to, it will be automated. Even if I haven't written the scripts yet, I will do it before the new machine comes up. Back when the system was created I had never been a "TDDer" before and the tools that exist now did not exist or were not viable for production, especially in terms of automated deployment and dependency management. If I could go back and do it again (or just murder someone) I'd love to have good test coverage and automation tools. It isn't that it's not important, it's just that the ship has sailed on half of it and the other half is situation-dependent at this stage. In summary, it is THAT important. I will go as far to say that I think these two items in particular are more or less vital to the long-term viability of a software project. Anyone maintaining a large, aged project that contains no test coverage and no automated build / deploy tools has my deepest sympathies; it's like stacking an infinite house of cards.
- mechanical_fish 17y ago
  Back when the system was created I had never been a "TDDer" before and the tools that exist now did not exist... Amen. I think a lot of the heated arguments about the value of testing arise from the fact that not everybody is using the same toolset. I'm sure unit testing in C is a major pain in the neck. (Can anybody link me to a document suggesting how to do it?) I know that unit testing in PHP is no picnic. But testing in Ruby is a joy, because the Ruby community has lavished attention on the subject over the last five years and the language, the tools, the idioms, and the culture are highly developed.
akeefer 17y ago
That's a bad conclusion to make: it's the classic tradeoff between importance and urgency. If you only ever do the urgent stuff, the hair-on-fire-has-to-be-done-yesterday stuff, you'll never make time to get to long-term strategic projects. The payoff for something like unit testing, automated deployment, and continuous integration are over the very, very long haul. If your cost/benefit analysis is always looking at 3- or 6-months out, it'll never seem like a win. So if you only ever do the urgent stuff and never anything strategic, 3 years later you'll realize that if you'd just sucked it up back at the start and done that stuff, even if meant putting off otherwise urgent features, you'd be further ahead than you are now, because it would have more than made up for the initial investment. So it's not that you don't do those things because they're not important, but rather because they're never urgent, and because most people's time horizons, especially in a startup, are fairly short.
- Tichy 17y ago
  Still, in 3 years the company might already be bankrupt, and nobody would care about tests anymore. Bankrupt is maybe too extreme, but the particular code module you spent 3 months writing tests for might be replaced by some open source solution or just not being needed anymore. I kind of see your point, but I find it difficult to deduce a binding rule from all of this. Sometimes it is important to have tests, sometimes other things are more important. You still have to decide on an individual basis. Thing is, the TDD and technical debt evangelists are typically consultants. Consultants usually earn more money the longer a project takes, and their income is not tied to the yields of the project. Just something to take into consideration imo.
  - shiro 17y ago
    > Consultants usually earn more money the longer a project takes, and their income is not tied to the yields of the project. Well... that seems oversimplification. When I consult, I ask the price roughly based on the estimation of how much time I'm going to take, but ultimately it is the matter that how much value the client sees in the outcome. Note that the expected outcome and the price are agreed beforehand---if I bump into an unforeseen obstacle and take twice time as my estimation, I can't ask them twice price; basically the more I work, the less I make per hour. So (1) I have a very strong incentive to make sure my part works in time, and (2) There's less incentive to finish the work earlier than the initial estimation. Thus I tend to put effort to write tests and debugging aids within the time frame (or, in other words, I try to negotiate initial time frame including those tests). Certainly there's a different pressure on employees; they may adjust priorities and time frames more frequently. So, it is true that consultants make more money the longer the project takes, but the incentive is in making sure it won't take longer than expected, rather than making it take longer deliberately. (After all, if the consultant is doing ok, there are projects in waiting list so it's not much point to taking one project longer than necessary.)
abalashov 17y ago
it is not actually THAT important. Otherwise you would make the time. ... that's just a little presumptuous, with respect to the concrete facts and motivations involved...
- Tichy 17y ago
  Didn't mean it that way, and why do you think so? How else to judge importance than by "people pay for it/make time for it"?
- blasdel 17y ago
  It comes down to the fact that noone really has priorities, much less ranked ones -- there is only the priority, and it's whatever you're presently doing.

vsiva68 17y ago

My sentiments exactly. Joel's article is just unnecessarily long with very little real content. There are many different ways to develop - Some people like C++, some don't, some do TDD, some don't. You can never say this is the ONE true way to develop. Do what works for you, but just be aware of other points of view.