5 ms·

Rails, rails. rails. Everything is about Rails. David is a good guy, but I'm starting to wonder if he's ever built a moderately complex system, involving integr

Rails, rails. rails. Everything is about Rails. David is a good guy, but I'm starting to wonder if he's ever built a moderately complex system, involving integrations, message queues, several data stores, a handful of third-party libraries and APIs and deployed on more than 3 machines. TDD is a tool to manage complexity. It's an advice, not a recipe. Like any technology - it isn't a substitute for thinking.

sjtgraham 12y ago
> I'm starting to wonder if he's ever built a moderately complex system, involving integrations, message queues, several data stores, a handful of third-party libraries and APIs and deployed on more than 3 machines. Erm… Have you heard of 37Signals? > TDD is a tool to manage complexity. It's an advice, not a recipe. Like any technology - it isn't a substitute for thinking. I don't think you disagree with DHH here. The key point is TDD cargo-culting has encouraged codebases to become deformed beyond recognition in pursuit of unit isolation, which btw provides no guarantee that a system even works end to end.
- slavoingilizov 12y ago
  > which btw provides no guarantee that a system even works end to end. Nor shoud it. Some things you test in isolation, others you test together. I am not making fun of dhh or Basecamp (37signals is the company, not a system). I even read most of his stuff and admire him. All I'm saying is that there are many systems far more complex than Basecamp and when you cannot fit the whole thing into your head, TDD helps to divide and conquer. I am against blindly following TDD, but I am also against dismissing it because it gets in the way when building a Rails app.
zsombor 12y ago
I am quite sure that the Basecamp cluster contains tens of machines. It also features a rather clever caching design. Please don't try to justify a push towards simplicity as lack of ability to handle complexity.
- kasey_junk 12y ago
  A) I don't subscribe to the idea that building guis on data stores is in any way demeaning and/or easier than other kinds of development work. B) I do think that if that is the main kind of systems you write (and I could be mistaken but all of 37signals products look like that to me) it will impact on your design philosophies and your thinking about quality assurance in ways different than other sorts of systems. The requirements are completely different for a system that is taking info from a user, persisting, and giving it back to them later, than for a system that is processing information and acting on it. Those different requirements will drive different architectures and different QA processes. None of that means you can't document those requirements as automated tests at the beginning of your coding cycle.
praptak 12y ago
Same impression here, dated Jan 2013 after his diss on dependency injection, based on a single method toy example: http://david.heinemeierhansson.com/2012/dependency-injection-is-not-a-virtue.html http://david.heinemeierhansson.com/2012/dependency-injection...
erichmond 12y ago
That's precisely the problem. Many in the rails community do use it as a substitute for thinking. In general, I'm not the biggest DHH supporter (although, he's made me a ton of money, indirectly, via rails), but I do like that he's stirring the pot here. Back in the 90s and early 2000s, I wrote tests, when needed. Sometimes before application code, sometimes after, it was a discretionary tool that I had in my arsenal that helped me both solve problems and feel confident that "my code won't break". At some point in time the majority of the rails community decided that if you don't test, you're a terrible programmer. Full Stop. The problem with this was that testing tools were terrible at the time, RSpec, before it's API solidified was breaking every other release, things like capybara and selenium and watir, always kinda worked, but not really, and you'd often spend 10 minutes writing the business logic, and then 40 minutes writing tests, getting them to pass, wrestling with external dependencies, etc. Furthermore, because people were practicing test-based application design, you were constantly re-writing your codebase and your test suite, because if you're designing for tests, you're not designing for the domain, and as domain requirements changed, and broke your testing model, you basically had to fix everything, and you couldn't get a handle on the domain because you had to be ruled by tests. All that said, I do think tests are useful. TDD isn't as useful for me. My thoughts are in line with Rich Hickey who said: "Life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design." From http://www.codequarterly.com/2011/rich-hickey/ http://www.codequarterly.com/2011/rich-hickey/
DrJokepu 12y ago
In my experience as a system gets more and more complicated it is typically the interfaces between various things (e.g. integration) that become problematic. While the number of logic bugs increase linearly with the size of the system, interface / integration bugs increase exponentially. It is the integration tests that really keep madness at bay. TDD and unit tests can be useful, especially if you're working with a dynamic language, but nearly not as useful as integration tests and won't really help you with complexity.
- kasey_junk 12y ago
  It's this assumption that TDD is all about unit tests that I find interesting. I drive my code with integration tests I write ahead of time as well. Maybe it is just the crowds I run in, but I've never encountered this dogmatic assumption that unit tests are the only tests you should have.
  - MartinCron 12y ago
    I have seen that dogmatic assumption, but I feel that it has fallen out of fashion at least a little bit. Nobody is telling me that I am doing it wrong for insisting on tests at multiple layers of the pyramid.
  - djur 12y ago
    The TDD book I'm most familiar with, GOOS [1], advocates starting with integration tests and then using unit tests during the process of making the integration test work. This approach has always helped me stay focused on the real-world requirements of the feature while also having fast tests to rely on during development. [1]: http://www.growing-object-oriented-software.com/code.html http://www.growing-object-oriented-software.com/code.html
    - platz 12y ago
      I consider GOOS the most credible authority on how to build a project with TDD methods. It even uses a staticly-typed language, which is interesting because the most vocal adherants of TDD tend to be using dynamically-typed languages. I've read the book, but I'm not such an avid TDD'er myself, mostly because I'd probably be doing it wrong for quite a while before getting it right. It'd be great if other people who've read the book had any insights here on how it related to DHH's opinions.
dhh 12y ago
Everyone has their own definition of complexity. I make no mince about a decade worth of developing Basecamp is where I draw my primary experience from. That system is small by web scale standards -- only 70 million requests/day, 1.5 terabyte of DB data, half a petabyte of file storage, two data centers, and about 100 physical machines -- but probably still larger than 97% of all Rails apps. Also, plenty of data stores (memcached, redis, multiple MySQLs, solr), many 3rd party libs, job servers, integrations, and more. So no, it's no Facebook or Yahoo or Google. But it also isn't a toy system, except in the sense that we're still having so much fun playing with it.
- slavoingilizov 12y ago
  I am not dismissing Basecamp. I am just saying that in a large portion of the software world, applications are waaaay more complex than normal rails apps. And in that context, TDD makes sense if only to manage complexity. Even if you are not Facebook, but say Airbnb. If their tests are not fast enough and they cannot trust them to make decisions, they wouldn't be able to deploy in a reasonable time. And when slow tests lead to infrequent deployments, that's when the real problems begin. (Airbnb is an arbitrary choice which came from the top of my mind, not anything specific) My gut feeling is that >50% of software development happens in those complex apps and not rails apps. So dismissing TDD is just yet another extreme viewpoint, which many people will unfortunately take for granted.
  - edu 12y ago
    AFAIK Airbnb uses Ruby and Rails to some extent. An actual job offer lists it as a requisite: https://www.airbnb.com/jobs/departments/position/2192 https://www.airbnb.com/jobs/departments/position/2192
  - mempko 12y ago
    I think the counter argument may be that TDD actually adds complexity to a system by destroying the architecture. So I am interested in what particular arguments you have in how TDD manages complexity instead of increasing it.
- pistle 12y ago

sjtgraham 12y ago

> I'm starting to wonder if he's ever built a moderately complex system, involving integrations, message queues, several data stores, a handful of third-party libraries and APIs and deployed on more than 3 machines. Erm… Have you heard of 37Signals? > TDD is a tool to manage complexity. It's an advice, not a recipe. Like any technology - it isn't a substitute for thinking. I don't think you disagree with DHH here. The key point is TDD cargo-culting has encouraged codebases to become deformed beyond recognition in pursuit of unit isolation, which btw provides no guarantee that a system even works end to end.

slavoingilizov 12y ago
> which btw provides no guarantee that a system even works end to end. Nor shoud it. Some things you test in isolation, others you test together. I am not making fun of dhh or Basecamp (37signals is the company, not a system). I even read most of his stuff and admire him. All I'm saying is that there are many systems far more complex than Basecamp and when you cannot fit the whole thing into your head, TDD helps to divide and conquer. I am against blindly following TDD, but I am also against dismissing it because it gets in the way when building a Rails app.

zsombor 12y ago

I am quite sure that the Basecamp cluster contains tens of machines. It also features a rather clever caching design. Please don't try to justify a push towards simplicity as lack of ability to handle complexity.

kasey_junk 12y ago
A) I don't subscribe to the idea that building guis on data stores is in any way demeaning and/or easier than other kinds of development work. B) I do think that if that is the main kind of systems you write (and I could be mistaken but all of 37signals products look like that to me) it will impact on your design philosophies and your thinking about quality assurance in ways different than other sorts of systems. The requirements are completely different for a system that is taking info from a user, persisting, and giving it back to them later, than for a system that is processing information and acting on it. Those different requirements will drive different architectures and different QA processes. None of that means you can't document those requirements as automated tests at the beginning of your coding cycle.

praptak 12y ago

Same impression here, dated Jan 2013 after his diss on dependency injection, based on a single method toy example: http://david.heinemeierhansson.com/2012/dependency-injection-is-not-a-virtue.html http://david.heinemeierhansson.com/2012/dependency-injection...

erichmond 12y ago

That's precisely the problem. Many in the rails community do use it as a substitute for thinking. In general, I'm not the biggest DHH supporter (although, he's made me a ton of money, indirectly, via rails), but I do like that he's stirring the pot here. Back in the 90s and early 2000s, I wrote tests, when needed. Sometimes before application code, sometimes after, it was a discretionary tool that I had in my arsenal that helped me both solve problems and feel confident that "my code won't break". At some point in time the majority of the rails community decided that if you don't test, you're a terrible programmer. Full Stop. The problem with this was that testing tools were terrible at the time, RSpec, before it's API solidified was breaking every other release, things like capybara and selenium and watir, always kinda worked, but not really, and you'd often spend 10 minutes writing the business logic, and then 40 minutes writing tests, getting them to pass, wrestling with external dependencies, etc. Furthermore, because people were practicing test-based application design, you were constantly re-writing your codebase and your test suite, because if you're designing for tests, you're not designing for the domain, and as domain requirements changed, and broke your testing model, you basically had to fix everything, and you couldn't get a handle on the domain because you had to be ruled by tests. All that said, I do think tests are useful. TDD isn't as useful for me. My thoughts are in line with Rich Hickey who said: "Life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design." From http://www.codequarterly.com/2011/rich-hickey/ http://www.codequarterly.com/2011/rich-hickey/

DrJokepu 12y ago

In my experience as a system gets more and more complicated it is typically the interfaces between various things (e.g. integration) that become problematic. While the number of logic bugs increase linearly with the size of the system, interface / integration bugs increase exponentially. It is the integration tests that really keep madness at bay. TDD and unit tests can be useful, especially if you're working with a dynamic language, but nearly not as useful as integration tests and won't really help you with complexity.

kasey_junk 12y ago
It's this assumption that TDD is all about unit tests that I find interesting. I drive my code with integration tests I write ahead of time as well. Maybe it is just the crowds I run in, but I've never encountered this dogmatic assumption that unit tests are the only tests you should have.
- MartinCron 12y ago
  I have seen that dogmatic assumption, but I feel that it has fallen out of fashion at least a little bit. Nobody is telling me that I am doing it wrong for insisting on tests at multiple layers of the pyramid.
- djur 12y ago
  The TDD book I'm most familiar with, GOOS [1], advocates starting with integration tests and then using unit tests during the process of making the integration test work. This approach has always helped me stay focused on the real-world requirements of the feature while also having fast tests to rely on during development. [1]: http://www.growing-object-oriented-software.com/code.html http://www.growing-object-oriented-software.com/code.html
  - platz 12y ago
    I consider GOOS the most credible authority on how to build a project with TDD methods. It even uses a staticly-typed language, which is interesting because the most vocal adherants of TDD tend to be using dynamically-typed languages. I've read the book, but I'm not such an avid TDD'er myself, mostly because I'd probably be doing it wrong for quite a while before getting it right. It'd be great if other people who've read the book had any insights here on how it related to DHH's opinions.

dhh 12y ago

Everyone has their own definition of complexity. I make no mince about a decade worth of developing Basecamp is where I draw my primary experience from. That system is small by web scale standards -- only 70 million requests/day, 1.5 terabyte of DB data, half a petabyte of file storage, two data centers, and about 100 physical machines -- but probably still larger than 97% of all Rails apps. Also, plenty of data stores (memcached, redis, multiple MySQLs, solr), many 3rd party libs, job servers, integrations, and more. So no, it's no Facebook or Yahoo or Google. But it also isn't a toy system, except in the sense that we're still having so much fun playing with it.

slavoingilizov 12y ago
I am not dismissing Basecamp. I am just saying that in a large portion of the software world, applications are waaaay more complex than normal rails apps. And in that context, TDD makes sense if only to manage complexity. Even if you are not Facebook, but say Airbnb. If their tests are not fast enough and they cannot trust them to make decisions, they wouldn't be able to deploy in a reasonable time. And when slow tests lead to infrequent deployments, that's when the real problems begin. (Airbnb is an arbitrary choice which came from the top of my mind, not anything specific) My gut feeling is that >50% of software development happens in those complex apps and not rails apps. So dismissing TDD is just yet another extreme viewpoint, which many people will unfortunately take for granted.
- edu 12y ago
  AFAIK Airbnb uses Ruby and Rails to some extent. An actual job offer lists it as a requisite: https://www.airbnb.com/jobs/departments/position/2192 https://www.airbnb.com/jobs/departments/position/2192
- mempko 12y ago
  I think the counter argument may be that TDD actually adds complexity to a system by destroying the architecture. So I am interested in what particular arguments you have in how TDD manages complexity instead of increasing it.
pistle 12y ago