i had a similar path to DHH - didn't identify with programming under computer science so i studied linguistics and history. now i've come to programming as a fun creative way to solve problems. absolutely loved this talk - will try to rewrite more of my old code and develop an eye for presenting concepts in code
You can't test for quality. Ruby looks like a modern small talk that's modern and business friendly. And clear to look at all day long. Not necessary a bad thing. Lo and behold.
I enjoyed this talk, DHH precisely telling programmers where they are losing there path of writing understandable, readable and maintainable code. Write code which makes yourself satisfied and feel proud about it.
This is still good stuff. Patterns were never meant to be learned and applied. Patterns were discovered, a lot of people did the same things, so they gave the thing a name. It's nice to have experience with a bunch of use-cases so you know which pattern comes close. It gets you closer to the draft. But then you tailor it and you make it clearer. Same with TDD, the only reason I write tests first is that I loath repetitive manual stuff. So my tests do the method calls so I can make it clearer while still knowing it works. If you're really want to do TDD, then at least don't forget about the blue step. Refactor. Also, don't forget about the concept that your code should become more generic while your tests become more precise.
Great talk, there's a lot of truth in here. I too think writing software is more of an art than science. "Programming is a lot more like french poetry than it is like physics" (40:46). Very accurate!
With respect, I don't want french poetry to determine how my car works. I don't want french poetry to protect my privacy. I don't want "pretty nice code that works ok, I think," to be the basis of my Company's information systems. He mistakes the most fundamental truth, when he claims. "When code is crap, it just needs to be rewritten." Nothing about professional disciplines matters, and "every single time" it just covers up the "crap." Code can't be rewritten -- its too expensive. Just too expensive. Iterating through "poetically beautiful," but non-extensible and non-maintainable code is unaffordable. This is something EVERYBODY who wrote a Rails App experienced. You go fast, blindingly fast. At first. Then, things get hard to change. Hard to maintain. They become fragile, immutable and awful. Yes, because the code was crap. It didn't use reasonable architectures and disciplines to build it (not the framework's fault, its just easy to do write shitty code, PARTICULARLY when you are going fast). Nobody can afford to press the Delete Key. If it were built with greater appreciation for the physics than the poetry, well, it would be better. At the end of the day, cowboy coding is just cowboy coding. Yeee-haaaa!
Andrew C. Greenberg I don't believe this video addresses Critical Systems such as the ones you mentioned. Rewriting code is only super expensive if you don't consider the short Agile cycles (which, again, is not used for critical systems). And, yes, it is poetry (for non-critical systems [again], the client is always changing his mind about what they want and what they "get" from the system, so is more an subjective task driven by the human subconsciousness, than objective - certainly making physical approaches more error prone and A LOT more expensive).
I watched this again and it still makes me think. In fact, I think I have habits that reset when I go to sleep, maybe I should watch this every 6 months?
Thank you, I always felt like I didn't write code "correctly" because I was writing code towards the usual standards. Now I know that I should write in a way the helps be me super productive and that I'm comfortable with :)
I think DHH is missing something by not acknowledging the interface between unit testing and a compiler/type system. Unit testing is popular for untyped, interpreted programming languages. Unit tests are a bandaid for dearth of information implied by the loss of a compiler. Interpreted programming languages are a response to the difficulty of using old languages like C++. We are entering a new realm of programming languages where a strong type system is still ergonomic. We will move beyond ruby and python and only then will we leave unit tests behind. That being said, I greatly value his statement of "Software Writer". I think that's a great thought that moves us forward.
AI generated summary: 00:48 🎉 David Heinemeier Hansson celebrates ten years of sharing Ruby on Rails with the community. 02:41 🖥 DHH learned programming at around age 20, debunking the misconception that all successful programmers start at a very young age. 04:08 🕹 DHH's early fascination with computers, starting with gaming on a Commodore 64. 05:59 📝 DHH's first attempt at programming involved creating a system to communicate with his mom using a pre-recorded message. 09:45 📠 DHH's involvement with BBS systems before the internet. 12:33 🧠 DHH's realization that he wasn't a computer scientist but focused on building information systems. 16:45 📜 DHH criticizes the notion of trying to establish "laws" in programming, comparing it to subjective fields like poetry analysis. 19:34 🧪 DHH believes that many software development methodologies are akin to pseudoscience, often offering simplified solutions. 22:48 🤔 DHH addresses the insecurity many programmers feel about their code quality and warns against falling for "one-size-fits-all" solutions. 23:46 🚫 TDD (Test-Driven Development) is a popular practice that emphasizes writing tests before code. It has a strong influence in the programming community, but it can make developers feel inadequate if not followed strictly. 28:03 🧪 The focus on making code easy to test, a common measure of success in TDD, can lead to code that is not necessarily better or simpler, but rather more testable. 29:56 🎯 Higher-level testing (e.g., model and controller tests) can be more valuable than unit tests because they better reflect how the entire system functions together, as opposed to focusing on isolated units. 33:37 🕰 The emphasis on coverage, ratio, and speed in testing metrics can sometimes overshadow the importance of system-level testing, which is crucial for ensuring that the entire application works as intended. 39:11 📉 Test-First Development can lead to design deterioration, as it can result in code being structured in a way that prioritizes testability over overall system design. 44:27 💡 Kent Beck, a prominent advocate of TDD, suggests testing as little as necessary to achieve a certain level of confidence in the code's functionality, emphasizing practicality over strict adherence to TDD principles. 47:44 🖋 Clarity in code is achieved by being succinct without being terse, using simple language, and minimizing conceptual complexity. 48:10 🧠 Viewing software development as writing emphasizes the importance of clarity over testing or engineering-driven approaches. 49:33 📏 Clarity in code is not easily quantifiable; it requires developing an eye for what is clear and valuing clarity as a priority. 50:30 👁 Developing an eye for clarity starts with recognizing its importance and dedicating oneself to prioritizing it in software development. 51:57 📸 Becoming a good programmer, defined by writing clear code, involves reading and writing a substantial amount of code, similar to developing skills in photography. 53:22 📚 Reading a diverse range of code, even poor-quality code, is crucial for learning what constitutes clarity and improving one's coding skills. 54:46 🔄 Engaging in discussions and arguments about code can reveal that applying patterns to poorly written code may not enhance its clarity. 57:40 🖊 Treating code as a draft allows for the iterative process of rewriting and refining it to prioritize clarity, akin to the process of writing essays. 59:57 🖋 Rewriting code is essential for achieving clarity by omitting needless concepts, patterns, and practices that do not contribute to understanding.
dreamrOkelly: The doctor that washes his hands is like the coder that uses a linter. Try out stuff first, don't be afraid to break things (in your test environment ;-). And write tests where they make sense, like around expected results, around logic that makes decisions. Writing a test first for add(2,2) == 4 does not.
This is 100% true. So many time I get hung up on why does this not look more professional. I should just be writing practical code that makes sense and forget about what I think it should look like. Draft it and improve it. There is a time and place for TDD for sure and Patterns but we always overuse them. At least I do.
We are engineers who get things done and treat our skill as an art. TDD is helpful, somebody misused it and fell does not mean that its wrong. Its very easy to mistake TDD as "Test Driven Design", but its not. It servers as a great documentation of the behavior of your class. Now there is so much you can test in a data class which has just getters and setters. So screw coverage, that I agree with. All in all I dig some points but am against the notion that unit tests are bad in general. "As it requires experience to do good writing or design, same applies for TDD"
Comparing a piano to a computer is a bad analogy in my opinion. Making a piano does not tell you anything about how you should be playing it. But writing code for operating systems tell you a lot about how you should write code for softwares. Sure, there's a lot more to discover in the process of writing good software, no doubt about that.
i am not a coder, i am know where he is coming from trying to learn programming and failed so many time. the most amazing thing about ppl that change (or interrupt) the world by creating new structure or paradigm is always an outside thinker looking into the box of traditional teaching and cant understand why thing needs to be absolutely that way. people are lazy by nature and code should be simple for a lazy person to understand.
The problem with learning to code is that you cant develop anything with code, I tried to learn programming for 8 to 9 years since i was a kid but I couldnt get past the command prompt calculator level. When I found rails I was developing stuff like pinterest and twitter in 2 weeks. If you want to make stuff then you have to start with a framework.
+supbrotv you know there is more to programming than just building web sites right. You can do plenty with code that surpasses making a calculator but it depends what your goal are, but just know not all programmers want to be web developers.
Please first of all stop using the words code and coding. It's programming. And no, everything that you are currently using on your computer, every website you visit, every program you run, every game you play was programmed together. My advice to you is too start learning about computing.
Making business information systems is not science but usually applying some concepts from science (like math) to programming leads to better results than just trial-error-retrial -style programming. Clarity is a good goal. But it is not just about practice. What makes code messy is: program state, side-effects to the state, and interaction of multiple side-effects. TDD won't remove the program state, even if you move the state to the method parameters. Also TDD won't be good for exploratory coding like REPL-loop (/interactive) is. But maybe tests will lead to more "customer service"-style interfaces. Also doing duplicate coding (just like type systems in some sense) will ensure functionality (which is usually helpful in the maintenance phase).
Рік тому
MVC is taken granted? Maybe, but most developers completely misunderstand the purpose and can't apply it without major flaws. So, 9 years later, and we must still talk about it. Maybe the term MVC is not proper as it doesn't suggest that the code should be modular, and the modules should be highly encapsulated, kind of implementing MVC on the modules level, instead of the application level. That is my biggest issue with Rails, which the ViewComponents could kind of help with, but only if those are used properly, meaning in a highly encapsulated way, where they are individually testable and don't rely on stateful properties. If we apply MVC on the module level, then the framework itself can be completely encapsulated from the modules themselves too. And then we can look for a new term instead of View , as actions don't have to generate views, practically they can do anything, like talking to external APIs. And, actually, this is the case with Rails too - actions don't have to generate views, hence the term MVC doesn't apply anymore, while the core architecture of Rails builds around MVC. An ideal framework wouldn't enforce any architecture on the developers, in fact, an MVC implementation could be a module on its own that is just connecting to the core framework when the action requires it.
TDD isn't bad. But adopting it in every situation can be a terrible idea. Writing integration tests (that involve minimal mocking) and then writing your code is actually a pretty good experience which also gives you some surety at the end. TDD shouldn't be viewed as writing code that's perfect for testing in my opinion, it should be followed when writing tests is straightforward and does not involve a whole lot of mocking.
A lot of software engineering is not pseudo science. Those patterns are discovered after years of writing software, and they are also presented with several examples in their support. Sure they are a result of inductive reasoning rather than deductive reasoning, but that doesn't make them less scientific. They are replaceable. Comparing with general diet plans without any scientific basis is not what software patterns are in my opinion.
I think you're a great speaker but I mostly disagree, here's why: Software Principles and Rules: Software principles like "The Law Of Demeter" are important and knowing about them do make programmers write better code, of course you can't just oblige to all those rules all the time, a good programmer knows when to oblige to a certain principle and when to dismiss it, trade offs almost always exist in software development. Readable Software: About code clarity, you can definitely get better at writing readable software by learning some rules and principles, have you ever read "The Art Of Readable Code" - It's a great book, you should try it out if you haven't already. TDD: Tests sometimes forces you to decouple code, it's not directly TDD's fault, and yet again there's a trade off here, reliability VS simplicity. IMHO a great software developer knows about the trade offs and chooses his actions wisely by the context, learning principles strengths your senses to identify good / bad code.
+EldanSai exactly I also don't agree with him about TDD... He's basically saying, somebody in the past made terrible architecture because of TDD and so don't do terrible architecture. well I think, the architecture would turn the wrong way even if authors of those projects he talks about didn't care as much about testing, it's not that making easily testable code inherently destroys code readability. He's fighting a straw man. Many projects achieve good testability and good readability and architecture. This guys talks a LOT of nonsense in other places as well
TDD tries to make programming science when it's actually an art - and that's what he has a problem with, just like many others (like myself). Tests first approach can lead to code with all tests passing, but are you sure you thought about *all* the scenarios that a well rounded/designed/built program can inherently take care of, even if tests aren't written for it? That's where the art vs science boundary lies in my opinion, and that's also where lies the fundamental problem with TDD.
Easier to test = easier to use. That's a fact. As for the test on the age and birthday...The test implementation is wrong. It wasn't needed at all to change the original code. Just create a date (of today), substract 7 years to it, and set this date as the birthday to the class Person. Boom, that test can never fail. Also he's proving the point of TDD here, as his original code is simpler to use, and he'd have seen that using TDD. Oh and by the way, the code has a bug, as a birthday is about month and day too, maybe he could have seen that by thinking about how he'd use it writing a test first ? ;) As for controllers, you don't unit test those, it's ineffective, you use integration tests instead.
Actually a quite good comment and sadly, without any likes. Exactly what I thought... the examples are poorly chosen, the statements exaggerated and DHH, ironically, sounds like a diet salesman:). While I agree with some things he said.. still the video is full of over exaggeration and quick conclusions,
For a process to be reliable and agile, the output of every of its stages has to be validated before it's received by the next one. Or there can be errors that only appear in special situations, and its fixing will be much costly than preventing them.
This speaks exactly what I think about TDD and first priority of writing code.
Рік тому
Watching this keynote again after almost a decade, I can't help but feel DHH was too optimistic about MVC becoming taken for granted. From my experience, it seems like developers still often misunderstand or misapply it, leading to some major flaws in their applications. One thing that strikes me is how MVC isn't really a one-size-fits-all solution for application design. In my view, it works best on a modular level, where each component is highly encapsulated and can be tested on its own. And speaking of Rails, I've always found that the ViewComponents, while a good step in the right direction, still fall short of this ideal. They don't encapsulate the database at the component level, and they're essentially just views, not distinct modules. I've started thinking that a framework shouldn't impose a specific architecture like MVC on developers. Instead, it could allow MVC to be an optional choice for modules that need it and let other modules connect to the core framework as needed. Actions within these modules could then do more than just generate views-they could handle any task like interfacing with external APIs. To me, this would open the door for the core framework to adopt the Hexagonal architectural pattern while still supporting MVC. It's a way to break free from the traditional constraints of MVC and make the software development processes more flexible and robust.
I coded in Amos. was so cool! I didn't get very far beyond animating a helicopter gif. I share your exact frustrations at the time. Im born in the mid 70's. I wish we had the resources we have today back then, or i had someone to teach or mentor me. But none of that was available.
Very true #dhh , wasting so much of time writing unit tests is not worth it. #unless was my favorite keyword as well if not imagine the pain to write the condition. I too don't want to move to any other language now after using #ruby or #rails too .....
And yet another perspective by Uncle Bob Martin. After respectfully acknowledging DHH, and without using a single four-letter word, he proposes a direct response to the straw men: blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html
DHH's example why TDD failed him in Basecamp was precisely a question of code coverage and lack of integration tests. Perhaps he might reconsider the virtues of code coverage rather than abandon a useful programming practice.
Linux is a monolith kernel created by Linus Torvalds in 1991; one year after, Andrew Tanenbaum (creator or MINIX microkernel) wrote an article for Usenet considering obsolete. Twenty fives years later we may say that Linux is not more alive than ever but also inside 1.4 billion of Android devices. At version 3.13, the code has already surpassed 9 million code lines and until 2010 there was no TDD (date of first Linux Test Project commit). The tests are community driven, depending strongly on community review. It possible write great software with or without TDD, BDD, MVP, MVC, etc. One should understand that they are not universals truths that should obeyed, but mere tools like hammers or saws are to a carpenter.
Make sure you don't isolate your code from the framework, so that you stay married to it. Make sure your controller does multiple things so that you can't inject or extend it. Screw DI and IoC cause who needs it when you have a framework that does it all :) DHH is a good businessman / charismatic speaker, I am almost convinced.
Thanks DHH. It changed my opinion. Now, I would say TDD helps you write a first draft of code that can be shipped with confidence and that won't be a masterpiece. I liked how engineer term is replaced by writer.
ok, so some great points about the misuse of TDD, but apart from that he's ranting about all the problems he's had about this method and quoting misconceptions as if they were fact. Yes, the religious advocates of TDD need to be reigned in, but TDD was never intended to be a silver bullet. Everything is software development is about trade-offs, it's better to learn the trade off's rather than throwing the baby out with the bath water and jumping on the next bandwagon. The only thing he's going to achieve is turning the staunch advocates of TDD into staunch haters of TDD.
I love this talk. I do have one point to make, no one will ever allow others to go without undue criticism. Take for example, even in the writing world, the debate (fights) between Faulkner and Hemingway. Faulkner actually insulted Hemingway for using 'small' words. Just wanted to bring that up ;) www.openculture.com/2014/07/faulkners-review-of-ernest-hemingways-the-old-man-and-the-sea.html
Replace the TDD in this video with Agile, would make as much sense as the original, i.e. agile started as a good sensible think at the time and look where are we now with it.
DHH probably does not know to do TDD correctly. At 27:49 he changes the public interface of the class so that he can pass the date. This is a strawman if there ever was one. What he should have done, is have a member variable of type DateProvider interface. This member variable would be injected though the constructor. Main (the wiring class) would supply a concrete implementation eg RealDateProvider (which will wrap the Date.today call). From the tests, instead of wiring a RealDateProvider, you wire a MockDateProvider (which would return a fixed date)
Sounds like he reached the bottom of TDD's hype cycle(en.wikipedia.org/wiki/Hype_cycle_ . I respect DHH a lot, but I think the diet hype analogy is a bit unfair. Also clearly biased to some "teachings" as the "unversal wisdom" (eg. TDD ruins the architecture) - basically doing the the same thing as the ones he complains about (the "self proclaimed" sw engineers promoting the TDD as being the only way). So, interesting thoughts (eg. sw is as much art as engineering), but no overall enlightenment of course.. Just the other side of the coin - presented that way, it would make much more sense.
The main point of this talk for me wasn´t TDD but what makes a good programmer and a good software. Just read and write a lots of software and learn from it.
+1 and right on. Having developed complicated web apps in PHP, .NET and (mainly) Java, I believe we need to just write more code in particular to improve. Methodologies/frameworks/libraries/languages/etc... come and go all the time...in the end of it all, we write code that somebody (hopefully) uses...so go write code!
This talk makes me angry about what was discussed over the past 2 weeks. Do you really need to say " #TDD is shit" just because your dev team is forcing APIs to be testable? Forcing API changes for testability is wrong anyway, and is by far TDD. You are not "driving" design, you are forcing it, which i different, and it is a mistake. I also just dislike how he dismisses years and years of studies and accumulated knowledge about software engineering as a "religion" or "cult". Otherwise, a lot of great points, but this talk still just makes me angry.
I can just completely agree with what you just wrote, ***** I personally never reached a case where code became uglier because of tests. Maybe a couple of exceptions, but I was new to TDD and I had no idea about what I was doing.
Who claims that unit testing suffices? DHH claims I do, but I don't. Who claims that easy testing is better just because? DHH claims I do, but I don't. Who claims that test metrics are the only measure of code quality? DHH claims I do, but I don't. So, no problem. My justifications for testing survive the non-argument, and are not answered by the rant. The bottom line began with his indication that he doesn't appreciate engineering and never got it. So, he argues instead that programming is like writing French Poetry, because he got that. His complaint about "the massive investment" in testing (nobody in the field believes that) ignores the massive investment in bad legacy code, fragile, unchangeable, unimprovable and actually ugly code. He accuses others of adopting religious beliefs about programming because they do that thing, and not the other thing. Pot. Kettle. Black. We agree on one thing: he is not a Software Engineer. He doesn't even know what Software Engineering, or he might. What is clear is that he doesn't know how to criticize Software Engineering, substituting a straw man to dis it. What supports his assertion that tests "don't do shit?" Nothing. He says it, but he doesn't support it. (Perhaps he doesn't get it, but I think he's just avoiding the argument to support his ideology.) Tests exist to free me to refactor and clean up my code. I can rebuild my system from the tests, but I can't rebuild my tests from the code. Tests make me go faster, and my code *is* better, clearer and well-documented. He claims he thought about this "a long time," but he really didn't manifest any of that thought. The talk is just pabulum. A much more practical defense of testing is available, it just isn't proffered using four-letter words. Ask yourself why you would prefer the cursing to the reasoning.
***** I think DHH is using Test::Unit to make his case, old fashioned testing where you can't just stub a global dependency. DHH has always been an advocate of Test::Unit, I'll use Test::Unit occasionally for gems and such when I don't want to introduce a 3rd party gem dependency, I'll probably start using minitest though since it's in the std lib.
Marco Pivetta His talk just made me laugh. I agree that he made some valid points, but the way he summarizes things is obviously to gain attention and garner contention. I was at this conference, saw this keynote, and watched every presentation that followed start with "Well DHH doesn't like this, but today I'm going to talk about...."
This had me laughing and feeling sorry for DHH. I've never heard of him before today but all I could think of the entire time was, this guy is talking about amateur problems. It's ok to be an amateur, and ya...most people do TDD wrong. But let's not confuse that with the fact that bad practices have led to his issues LOL. What a riot.
krzemianpl The good practise of TDD is this: do not do TDD, but instead write very simple tests for each method you create. Check every piece of code you write. But let your own creativity drive the design, because you only have the needed information when doing not before.
Brandon Kindred was only six years developer in his life, and he talks about "amateur problems"? He is basically on his way from junior to mid-level as a developer. I can only imagine how unlucky are developers that he manages now.
zardthebard Like "TDD is something that have lots of mocks that not really test your app". It is a critic to the mocking obsession, not TDD. This means that he attacks some styles of TDD - and other stuff more or less related. It is a misrepresentation of the original topic of argument, so a straw man.
Hearing DHH talk about things is so frustrating. He has so many good things to say and then he thoroughly taints his message by bashing on TDD when his understanding of TDD is completely flawed. And it makes it impossible for me to recommend his stuff to others. I am a major proponent of TDD to the point that I think that not using it is arguably unprofessional, and not a single one of his generalizations about TDD proponents applies to me. 1. Using the “travel_to” method is totally fine. TDD has nothing against doing that. I’m sure that there are proponents of TDD who will say “nonono, use dependency injection,” but that is the opinion of those people and has nothing to do with TDD. 2. With all of these methods where “now” is injected, how is TDD driving out “(now=Date.today)”? If I can delete that code and my tests still pass, then I didn’t use TDD to write it. It’s actually impossible to use TDD to get to the dependency injection that he’s describing here. With TDD, you MUST mock Date.today in order to use it at all. The actual point of doing it the way he describes is that mocking Date.today like that has historically been impossible in a lot of languages, so you couldn’t test that at all, and that was the best way to handle that untestable piece of code. The fact that people learned to do it that way and are too set in their ways to adjust to newer testing capabilities is in no way a reflection on TDD. 3. Readability and the ability to reason about code is almost always more important than how easy it is to test. One of the main points of TDD is to get you to easy to read about code by making constant refactoring part of your cycle. 4. With the PeopleController, the kind of mocking he describes is absolutely anathema to TDD. TDD is the red->green->refactor cycle. The “refactor” part of that cycle is both the most important part of that cycle and the part that most often gets ignored by people who don’t understand TDD. If you mock in the way that he describes, it is impossible to refactor. Therefor, a person doing that can’t possibly be doing TDD. They might be doing “test first,” but they aren’t doing TDD. 5. “Most Unit Testing is Waste” - The problem with this quote and everything DHH says about it is that there is an inherent assumption that what he thinks “unit testing” means is the same as what everyone else thinks “unit testing” means. Some people have gotten the idea that “isolating the code under test” means that you mock everything that you test the function a code is in and either inject or mock everything related to that function. If that is the definition for “unit test,” then TDD isn’t and never was about unit tests, because that sort of test prevents you from refactoring, which means that you are prevented from doing TDD. The TDD idea of “isolating the code under test” simply means that you are just testing one piece of logic and have controlled everything else. You could be running a test through a Rails controller that hits a service that hits another service that hits a model to find the piece of logic it’s testing, and so long as everything else is controlled and you’re just testing that one bit of logic, that’s a TDD unit test. Is TDD focused on the unit? That depends entirely on how you define unit. 6. He repeatedly equates TDD with “test first.” That’s like equating mammals with animals, pointing at a fish, and saying, “that’s a mammal, and it has no fur, so mammals aren’t real.” Ultimately, the type of people that DHH thinks are proponents of TDD aren’t practicing TDD at all. You might think that this is a “No true Scotsman” argument, but it isn’t. TDD is defined by the “red/green/refactor” cycle, and these people are writing tests that make refactoring (changing your code without changing your tests) completely impossible. I got 40 minutes in before I gave up. This would be such a great presentation is he could have just focused on the concepts he was talking about and not try to turn them into criticisms of TDD that actually have nothing to do with TDD.
Came back for the other 20 minutes! "Unless you're doing tests first, you're not a professional." The quality that makes one a professional is constantly refactoring things. Refactoring is the heart and soul of TDD (actual TDD, not merely "test first"). Constant refactoring is necessary for clean code, and great tests are necessary for constant refactoring. TDD is not necessarily the only way to get there, but the TDD process imprints thorough testing and constant refactoring into your bones. The problem with Active Record is that mixing concerns encourages people to write code that is harder to read. Most of the "rules" he's bashing here are rules for writing code that's more clear and readable. The problem is that while our jobs might indeed be more equivalent to writing, lots of devs aren't very good writers, so lots of devs will follow the rules religiously without understanding their purpose. If they're fussing at you about this, then yeah, it's annoying. But those sorts of people are there and annoying in all aspects of life. It doesn't mean the guidelines are bad. Everything he says about "drafts" at the end is exactly what TDD is all about. I could actually open a presentation about TDD with almost exactly what he said (except to forget about TDD)
Watch it twice in a row - so good - it hits a lot of my thinking.
i had a similar path to DHH - didn't identify with programming under computer science so i studied linguistics and history. now i've come to programming as a fun creative way to solve problems. absolutely loved this talk - will try to rewrite more of my old code and develop an eye for presenting concepts in code
You can't test for quality. Ruby looks like a modern small talk that's modern and business friendly. And clear to look at all day long. Not necessary a bad thing. Lo and behold.
I enjoyed this talk, DHH precisely telling programmers where they are losing there path of writing understandable, readable and maintainable code.
Write code which makes yourself satisfied and feel proud about it.
This is still good stuff. Patterns were never meant to be learned and applied. Patterns were discovered, a lot of people did the same things, so they gave the thing a name. It's nice to have experience with a bunch of use-cases so you know which pattern comes close. It gets you closer to the draft. But then you tailor it and you make it clearer.
Same with TDD, the only reason I write tests first is that I loath repetitive manual stuff. So my tests do the method calls so I can make it clearer while still knowing it works.
If you're really want to do TDD, then at least don't forget about the blue step. Refactor. Also, don't forget about the concept that your code should become more generic while your tests become more precise.
great talk, enjoyed his enthusiasm about the need for system testing, one of the best keynotes I have seen in recent times
Great talk, there's a lot of truth in here. I too think writing software is more of an art than science. "Programming is a lot more like french poetry than it is like physics" (40:46). Very accurate!
With respect, I don't want french poetry to determine how my car works. I don't want french poetry to protect my privacy. I don't want "pretty nice code that works ok, I think," to be the basis of my Company's information systems.
He mistakes the most fundamental truth, when he claims. "When code is crap, it just needs to be rewritten." Nothing about professional disciplines matters, and "every single time" it just covers up the "crap."
Code can't be rewritten -- its too expensive. Just too expensive. Iterating through "poetically beautiful," but non-extensible and non-maintainable code is unaffordable.
This is something EVERYBODY who wrote a Rails App experienced. You go fast, blindingly fast. At first. Then, things get hard to change. Hard to maintain. They become fragile, immutable and awful. Yes, because the code was crap. It didn't use reasonable architectures and disciplines to build it (not the framework's fault, its just easy to do write shitty code, PARTICULARLY when you are going fast).
Nobody can afford to press the Delete Key. If it were built with greater appreciation for the physics than the poetry, well, it would be better.
At the end of the day, cowboy coding is just cowboy coding. Yeee-haaaa!
Andrew C. Greenberg I don't believe this video addresses Critical Systems such as the ones you mentioned. Rewriting code is only super expensive if you don't consider the short Agile cycles (which, again, is not used for critical systems). And, yes, it is poetry (for non-critical systems [again], the client is always changing his mind about what they want and what they "get" from the system, so is more an subjective task driven by the human subconsciousness, than objective - certainly making physical approaches more error prone and A LOT more expensive).
I watched this again and it still makes me think. In fact, I think I have habits that reset when I go to sleep, maybe I should watch this every 6 months?
DHH always making us rethink. Awesome.
Thank you, I always felt like I didn't write code "correctly" because I was writing code towards the usual standards. Now I know that I should write in a way the helps be me super productive and that I'm comfortable with :)
I love this guy.
Similar path but started later.
It's been a fun ride so far.
I think DHH is missing something by not acknowledging the interface between unit testing and a compiler/type system. Unit testing is popular for untyped, interpreted programming languages. Unit tests are a bandaid for dearth of information implied by the loss of a compiler. Interpreted programming languages are a response to the difficulty of using old languages like C++. We are entering a new realm of programming languages where a strong type system is still ergonomic. We will move beyond ruby and python and only then will we leave unit tests behind.
That being said, I greatly value his statement of "Software Writer". I think that's a great thought that moves us forward.
AI generated summary:
00:48 🎉 David Heinemeier Hansson celebrates ten years of sharing Ruby on Rails with the community.
02:41 🖥 DHH learned programming at around age 20, debunking the misconception that all successful programmers start at a very young age.
04:08 🕹 DHH's early fascination with computers, starting with gaming on a Commodore 64.
05:59 📝 DHH's first attempt at programming involved creating a system to communicate with his mom using a pre-recorded message.
09:45 📠 DHH's involvement with BBS systems before the internet.
12:33 🧠 DHH's realization that he wasn't a computer scientist but focused on building information systems.
16:45 📜 DHH criticizes the notion of trying to establish "laws" in programming, comparing it to subjective fields like poetry analysis.
19:34 🧪 DHH believes that many software development methodologies are akin to pseudoscience, often offering simplified solutions.
22:48 🤔 DHH addresses the insecurity many programmers feel about their code quality and warns against falling for "one-size-fits-all" solutions.
23:46 🚫 TDD (Test-Driven Development) is a popular practice that emphasizes writing tests before code. It has a strong influence in the programming community, but it can make developers feel inadequate if not followed strictly.
28:03 🧪 The focus on making code easy to test, a common measure of success in TDD, can lead to code that is not necessarily better or simpler, but rather more testable.
29:56 🎯 Higher-level testing (e.g., model and controller tests) can be more valuable than unit tests because they better reflect how the entire system functions together, as opposed to focusing on isolated units.
33:37 🕰 The emphasis on coverage, ratio, and speed in testing metrics can sometimes overshadow the importance of system-level testing, which is crucial for ensuring that the entire application works as intended.
39:11 📉 Test-First Development can lead to design deterioration, as it can result in code being structured in a way that prioritizes testability over overall system design.
44:27 💡 Kent Beck, a prominent advocate of TDD, suggests testing as little as necessary to achieve a certain level of confidence in the code's functionality, emphasizing practicality over strict adherence to TDD principles.
47:44 🖋 Clarity in code is achieved by being succinct without being terse, using simple language, and minimizing conceptual complexity.
48:10 🧠 Viewing software development as writing emphasizes the importance of clarity over testing or engineering-driven approaches.
49:33 📏 Clarity in code is not easily quantifiable; it requires developing an eye for what is clear and valuing clarity as a priority.
50:30 👁 Developing an eye for clarity starts with recognizing its importance and dedicating oneself to prioritizing it in software development.
51:57 📸 Becoming a good programmer, defined by writing clear code, involves reading and writing a substantial amount of code, similar to developing skills in photography.
53:22 📚 Reading a diverse range of code, even poor-quality code, is crucial for learning what constitutes clarity and improving one's coding skills.
54:46 🔄 Engaging in discussions and arguments about code can reveal that applying patterns to poorly written code may not enhance its clarity.
57:40 🖊 Treating code as a draft allows for the iterative process of rewriting and refining it to prioritize clarity, akin to the process of writing essays.
59:57 🖋 Rewriting code is essential for achieving clarity by omitting needless concepts, patterns, and practices that do not contribute to understanding.
I have a question. If I am writing a UI test then how can I NOT call the actual webservices. For those scenarioes, I will end up using Mocks.
Thank you for letting me know I'm not a total outsider for not strictly following TDD.
Dr. Who?
...or Dr. Poo? :-/
#Ecchhh
dreamrOkelly: The doctor that washes his hands is like the coder that uses a linter. Try out stuff first, don't be afraid to break things (in your test environment ;-). And write tests where they make sense, like around expected results, around logic that makes decisions. Writing a test first for add(2,2) == 4 does not.
This is 100% true. So many time I get hung up on why does this not look more professional. I should just be writing practical code that makes sense and forget about what I think it should look like. Draft it and improve it. There is a time and place for TDD for sure and Patterns but we always overuse them. At least I do.
We are engineers who get things done and treat our skill as an art. TDD is helpful, somebody misused it and fell does not mean that its wrong. Its very easy to mistake TDD as "Test Driven Design", but its not. It servers as a great documentation of the behavior of your class. Now there is so much you can test in a data class which has just getters and setters. So screw coverage, that I agree with. All in all I dig some points but am against the notion that unit tests are bad in general.
"As it requires experience to do good writing or design, same applies for TDD"
Comparing a piano to a computer is a bad analogy in my opinion. Making a piano does not tell you anything about how you should be playing it. But writing code for operating systems tell you a lot about how you should write code for softwares. Sure, there's a lot more to discover in the process of writing good software, no doubt about that.
i am not a coder, i am know where he is coming from trying to learn programming and failed so many time. the most amazing thing about ppl that change (or interrupt) the world by creating new structure or paradigm is always an outside thinker looking into the box of traditional teaching and cant understand why thing needs to be absolutely that way. people are lazy by nature and code should be simple for a lazy person to understand.
No
Fucking awesome, this is what i always try to explain to people, DHH has hit bullseye
I really enjoyed this talk.
Me too.
+Tyler Merritt As did I, it gave me a new perspective on software development in general.
The problem with learning to code is that you cant develop anything with code, I tried to learn programming for 8 to 9 years since i was a kid but I couldnt get past the command prompt calculator level. When I found rails I was developing stuff like pinterest and twitter in 2 weeks. If you want to make stuff then you have to start with a framework.
+supbrotv So true. If you wanna make money and get the job done don't waste too much time on the language itself. Just jump to the framework.
+supbrotv you know there is more to programming than just building web sites right. You can do plenty with code that surpasses making a calculator but it depends what your goal are, but just know not all programmers want to be web developers.
Nick Ellis true, but most people that learn code want to create apps and you cant really create anything that people can use with just code.
supbrotv
I was gonna be a dick and say that websites are all just code(even HTML&CSS), but i know what you mean. I see yr point.
Please first of all stop using the words code and coding. It's programming. And no, everything that you are currently using on your computer, every website you visit, every program you run, every game you play was programmed together. My advice to you is too start learning about computing.
Making business information systems is not science but usually applying some concepts from science (like math) to programming leads to better results than just trial-error-retrial -style programming.
Clarity is a good goal. But it is not just about practice. What makes code messy is: program state, side-effects to the state, and interaction of multiple side-effects. TDD won't remove the program state, even if you move the state to the method parameters. Also TDD won't be good for exploratory coding like REPL-loop (/interactive) is. But maybe tests will lead to more "customer service"-style interfaces. Also doing duplicate coding (just like type systems in some sense) will ensure functionality (which is usually helpful in the maintenance phase).
MVC is taken granted? Maybe, but most developers completely misunderstand the purpose and can't apply it without major flaws. So, 9 years later, and we must still talk about it. Maybe the term MVC is not proper as it doesn't suggest that the code should be modular, and the modules should be highly encapsulated, kind of implementing MVC on the modules level, instead of the application level. That is my biggest issue with Rails, which the ViewComponents could kind of help with, but only if those are used properly, meaning in a highly encapsulated way, where they are individually testable and don't rely on stateful properties.
If we apply MVC on the module level, then the framework itself can be completely encapsulated from the modules themselves too. And then we can look for a new term instead of View , as actions don't have to generate views, practically they can do anything, like talking to external APIs. And, actually, this is the case with Rails too - actions don't have to generate views, hence the term MVC doesn't apply anymore, while the core architecture of Rails builds around MVC.
An ideal framework wouldn't enforce any architecture on the developers, in fact, an MVC implementation could be a module on its own that is just connecting to the core framework when the action requires it.
TDD isn't bad. But adopting it in every situation can be a terrible idea. Writing integration tests (that involve minimal mocking) and then writing your code is actually a pretty good experience which also gives you some surety at the end. TDD shouldn't be viewed as writing code that's perfect for testing in my opinion, it should be followed when writing tests is straightforward and does not involve a whole lot of mocking.
A lot of software engineering is not pseudo science. Those patterns are discovered after years of writing software, and they are also presented with several examples in their support. Sure they are a result of inductive reasoning rather than deductive reasoning, but that doesn't make them less scientific. They are replaceable. Comparing with general diet plans without any scientific basis is not what software patterns are in my opinion.
I think you're a great speaker but I mostly disagree, here's why:
Software Principles and Rules:
Software principles like "The Law Of Demeter" are important and knowing about them do make programmers write better code, of course you can't just oblige to all those rules all the time, a good programmer knows when to oblige to a certain principle and when to dismiss it, trade offs almost always exist in software development.
Readable Software:
About code clarity, you can definitely get better at writing readable software by learning some rules and principles, have you ever read "The Art Of Readable Code" - It's a great book, you should try it out if you haven't already.
TDD:
Tests sometimes forces you to decouple code, it's not directly TDD's fault,
and yet again there's a trade off here, reliability VS simplicity.
IMHO a great software developer knows about the trade offs and chooses his actions wisely by the context, learning principles strengths your senses to identify good / bad code.
+EldanSai exactly I also don't agree with him about TDD... He's basically saying, somebody in the past made terrible architecture because of TDD and so don't do terrible architecture. well I think, the architecture would turn the wrong way even if authors of those projects he talks about didn't care as much about testing, it's not that making easily testable code inherently destroys code readability. He's fighting a straw man. Many projects achieve good testability and good readability and architecture. This guys talks a LOT of nonsense in other places as well
TDD tries to make programming science when it's actually an art - and that's what he has a problem with, just like many others (like myself). Tests first approach can lead to code with all tests passing, but are you sure you thought about *all* the scenarios that a well rounded/designed/built program can inherently take care of, even if tests aren't written for it? That's where the art vs science boundary lies in my opinion, and that's also where lies the fundamental problem with TDD.
Easier to test = easier to use. That's a fact.
As for the test on the age and birthday...The test implementation is wrong. It wasn't needed at all to change the original code. Just create a date (of today), substract 7 years to it, and set this date as the birthday to the class Person. Boom, that test can never fail. Also he's proving the point of TDD here, as his original code is simpler to use, and he'd have seen that using TDD.
Oh and by the way, the code has a bug, as a birthday is about month and day too, maybe he could have seen that by thinking about how he'd use it writing a test first ? ;)
As for controllers, you don't unit test those, it's ineffective, you use integration tests instead.
Actually a quite good comment and sadly, without any likes. Exactly what I thought... the examples are poorly chosen, the statements exaggerated and DHH, ironically, sounds like a diet salesman:). While I agree with some things he said.. still the video is full of over exaggeration and quick conclusions,
Unit testing everything is good as long it's done simple and after the coding.
For a process to be reliable and agile, the output of every of its stages has to be validated before it's received by the next one. Or there can be errors that only appear in special situations, and its fixing will be much costly than preventing them.
This speaks exactly what I think about TDD and first priority of writing code.
Watching this keynote again after almost a decade, I can't help but feel DHH was too optimistic about MVC becoming taken for granted. From my experience, it seems like developers still often misunderstand or misapply it, leading to some major flaws in their applications.
One thing that strikes me is how MVC isn't really a one-size-fits-all solution for application design. In my view, it works best on a modular level, where each component is highly encapsulated and can be tested on its own.
And speaking of Rails, I've always found that the ViewComponents, while a good step in the right direction, still fall short of this ideal. They don't encapsulate the database at the component level, and they're essentially just views, not distinct modules.
I've started thinking that a framework shouldn't impose a specific architecture like MVC on developers. Instead, it could allow MVC to be an optional choice for modules that need it and let other modules connect to the core framework as needed. Actions within these modules could then do more than just generate views-they could handle any task like interfacing with external APIs.
To me, this would open the door for the core framework to adopt the Hexagonal architectural pattern while still supporting MVC. It's a way to break free from the traditional constraints of MVC and make the software development processes more flexible and robust.
I coded in Amos. was so cool! I didn't get very far beyond animating a helicopter gif. I share your exact frustrations at the time. Im born in the mid 70's. I wish we had the resources we have today back then, or i had someone to teach or mentor me. But none of that was available.
tl;dr: software is art.
no its a religion
Bull shit
thanks for sharing Confreaks
Very true #dhh , wasting so much of time writing unit tests is not worth it. #unless was my favorite keyword as well if not imagine the pain to write the condition. I too don't want to move to any other language now after using #ruby or #rails too .....
And yet another perspective by Uncle Bob Martin. After respectfully acknowledging DHH, and without using a single four-letter word, he proposes a direct response to the straw men: blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html
Really helpful. thanks a lot. All naysayers will realize what DHH really means after "writing" software many times.. I hope.
DHH's example why TDD failed him in Basecamp was precisely a question of code coverage and lack of integration tests. Perhaps he might reconsider the virtues of code coverage rather than abandon a useful programming practice.
That's incorrect because you can have 100% unit test coverage and no integration tests.
Linux is a monolith kernel created by Linus Torvalds in 1991; one year after, Andrew Tanenbaum (creator or MINIX microkernel) wrote an article for Usenet considering obsolete. Twenty fives years later we may say that Linux is not more alive than ever but also inside 1.4 billion of Android devices.
At version 3.13, the code has already surpassed 9 million code lines and until 2010 there was no TDD (date of first Linux Test Project commit). The tests are community driven, depending strongly on community review.
It possible write great software with or without TDD, BDD, MVP, MVC, etc. One should understand that they are not universals truths that should obeyed, but mere tools like hammers or saws are to a carpenter.
Make sure you don't isolate your code from the framework, so that you stay married to it. Make sure your controller does multiple things so that you can't inject or extend it. Screw DI and IoC cause who needs it when you have a framework that does it all :) DHH is a good businessman / charismatic speaker, I am almost convinced.
He was at "The Party' in Denmark, not "The Gathering" :D
No
that was pretty fking good.
it makes a lot of sense.
Thanks DHH. It changed my opinion. Now, I would say TDD helps you write a first draft of code that can be shipped with confidence and that won't be a masterpiece.
I liked how engineer term is replaced by writer.
ok, so some great points about the misuse of TDD, but apart from that he's ranting about all the problems he's had about this method and quoting misconceptions as if they were fact. Yes, the religious advocates of TDD need to be reigned in, but TDD was never intended to be a silver bullet.
Everything is software development is about trade-offs, it's better to learn the trade off's rather than throwing the baby out with the bath water and jumping on the next bandwagon.
The only thing he's going to achieve is turning the staunch advocates of TDD into staunch haters of TDD.
I call it "test dictated development" when people write code that's built around the tests, instead of the tests built to support the code.
Very good points. He thinks "Outside the box".
"DHH is the Fox News of Ruby." After watching this, I understand this quote completely.
it is possible to test pretty whole system with capybara feature tests
I love this talk. I do have one point to make, no one will ever allow others to go without undue criticism. Take for example, even in the writing world, the debate (fights) between Faulkner and Hemingway. Faulkner actually insulted Hemingway for using 'small' words. Just wanted to bring that up ;)
www.openculture.com/2014/07/faulkners-review-of-ernest-hemingways-the-old-man-and-the-sea.html
I guess something we can learn from this is that you'll never have success if you never get things done-sucky programmer or not.
Replace the TDD in this video with Agile, would make as much sense as the original, i.e. agile started as a good sensible think at the time and look where are we now with it.
DHH probably does not know to do TDD correctly. At 27:49 he changes the public interface of the class so that he can pass the date. This is a strawman if there ever was one. What he should have done, is have a member variable of type DateProvider interface. This member variable would be injected though the constructor. Main (the wiring class) would supply a concrete implementation eg RealDateProvider (which will wrap the Date.today call). From the tests, instead of wiring a RealDateProvider, you wire a MockDateProvider (which would return a fixed date)
Sounds like he reached the bottom of TDD's hype cycle(en.wikipedia.org/wiki/Hype_cycle_
. I respect DHH a lot, but I think the diet hype analogy is a bit unfair. Also clearly biased to some "teachings" as the "unversal wisdom" (eg. TDD ruins the architecture) - basically doing the the same thing as the ones he complains about (the "self proclaimed" sw engineers promoting the TDD as being the only way).
So, interesting thoughts (eg. sw is as much art as engineering), but no overall enlightenment of course.. Just the other side of the coin - presented that way, it would make much more sense.
Here is a guy that's a master in justifying his misconceptions.
Could you please clear up his misconceptions? That would be of help to everyone who watches this.
'TDD is the most successful software diet of all time' lol
The main point of this talk for me wasn´t TDD but what makes a good programmer and a good software. Just read and write a lots of software and learn from it.
+1 and right on. Having developed complicated web apps in PHP, .NET and (mainly) Java, I believe we need to just write more code in particular to improve. Methodologies/frameworks/libraries/languages/etc... come and go all the time...in the end of it all, we write code that somebody (hopefully) uses...so go write code!
good testing and breaking upfunctions and writing good code are NOT mutually exclusive. dhh is a bad coder
DHH telling the world how to complect software.
A
"Empirical truths, blah blah blah, we have laws, blah blah blah". 18 mins in and so far, I think I like this guy.
This talk makes me angry about what was discussed over the past 2 weeks.
Do you really need to say " #TDD is shit" just because your dev team is forcing APIs to be testable?
Forcing API changes for testability is wrong anyway, and is by far TDD. You are not "driving" design, you are forcing it, which i different, and it is a mistake.
I also just dislike how he dismisses years and years of studies and accumulated knowledge about software engineering as a "religion" or "cult".
Otherwise, a lot of great points, but this talk still just makes me angry.
I can just completely agree with what you just wrote, *****
I personally never reached a case where code became uglier because of tests. Maybe a couple of exceptions, but I was new to TDD and I had no idea about what I was doing.
Who claims that unit testing suffices? DHH claims I do, but I don't. Who claims that easy testing is better just because? DHH claims I do, but I don't. Who claims that test metrics are the only measure of code quality? DHH claims I do, but I don't. So, no problem. My justifications for testing survive the non-argument, and are not answered by the rant.
The bottom line began with his indication that he doesn't appreciate engineering and never got it. So, he argues instead that programming is like writing French Poetry, because he got that. His complaint about "the massive investment" in testing (nobody in the field believes that) ignores the massive investment in bad legacy code, fragile, unchangeable, unimprovable and actually ugly code.
He accuses others of adopting religious beliefs about programming because they do that thing, and not the other thing. Pot. Kettle. Black. We agree on one thing: he is not a Software Engineer. He doesn't even know what Software Engineering, or he might. What is clear is that he doesn't know how to criticize Software Engineering, substituting a straw man to dis it.
What supports his assertion that tests "don't do shit?" Nothing. He says it, but he doesn't support it. (Perhaps he doesn't get it, but I think he's just avoiding the argument to support his ideology.) Tests exist to free me to refactor and clean up my code. I can rebuild my system from the tests, but I can't rebuild my tests from the code. Tests make me go faster, and my code *is* better, clearer and well-documented.
He claims he thought about this "a long time," but he really didn't manifest any of that thought. The talk is just pabulum. A much more practical defense of testing is available, it just isn't proffered using four-letter words. Ask yourself why you would prefer the cursing to the reasoning.
***** I think DHH is using Test::Unit to make his case, old fashioned testing where you can't just stub a global dependency. DHH has always been an advocate of Test::Unit, I'll use Test::Unit occasionally for gems and such when I don't want to introduce a 3rd party gem dependency, I'll probably start using minitest though since it's in the std lib.
mandokir well thank you. Please go to 4chan/b/ and express your very useful feedback there.
Marco Pivetta His talk just made me laugh. I agree that he made some valid points, but the way he summarizes things is obviously to gain attention and garner contention. I was at this conference, saw this keynote, and watched every presentation that followed start with "Well DHH doesn't like this, but today I'm going to talk about...."
This had me laughing and feeling sorry for DHH. I've never heard of him before today but all I could think of the entire time was, this guy is talking about amateur problems. It's ok to be an amateur, and ya...most people do TDD wrong. But let's not confuse that with the fact that bad practices have led to his issues LOL. What a riot.
Hey Brandon, what would you recommend as a source of good TDD practises?
krzemianpl
The good practise of TDD is this: do not do TDD, but instead write very simple tests for each method you create.
Check every piece of code you write. But let your own creativity drive the design, because you only have the needed information when doing not before.
Brandon Kindred his code made him a multi-millionaire tho...
He is a successful businessman that has created one of the worlds most popular framework. What have you accomplished?
Brandon Kindred was only six years developer in his life, and he talks about "amateur problems"? He is basically on his way from junior to mid-level as a developer. I can only imagine how unlucky are developers that he manages now.
TDD is meh, but if your code is hard to test, it's shit, period. "Hard to test" is the end result of crap design.
no
@@redhotbits yes
Good talk, good points... despite the straw man fallacy.
Where do you see a straw man? Have you not had to deal with this Law of Demeter shit?
zardthebard Like "TDD is something that have lots of mocks that not really test your app". It is a critic to the mocking obsession, not TDD.
This means that he attacks some styles of TDD - and other stuff more or less related. It is a misrepresentation of the original topic of argument, so a straw man.
Hearing DHH talk about things is so frustrating. He has so many good things to say and then he thoroughly taints his message by bashing on TDD when his understanding of TDD is completely flawed. And it makes it impossible for me to recommend his stuff to others. I am a major proponent of TDD to the point that I think that not using it is arguably unprofessional, and not a single one of his generalizations about TDD proponents applies to me.
1. Using the “travel_to” method is totally fine. TDD has nothing against doing that. I’m sure that there are proponents of TDD who will say “nonono, use dependency injection,” but that is the opinion of those people and has nothing to do with TDD.
2. With all of these methods where “now” is injected, how is TDD driving out “(now=Date.today)”? If I can delete that code and my tests still pass, then I didn’t use TDD to write it. It’s actually impossible to use TDD to get to the dependency injection that he’s describing here. With TDD, you MUST mock Date.today in order to use it at all. The actual point of doing it the way he describes is that mocking Date.today like that has historically been impossible in a lot of languages, so you couldn’t test that at all, and that was the best way to handle that untestable piece of code. The fact that people learned to do it that way and are too set in their ways to adjust to newer testing capabilities is in no way a reflection on TDD.
3. Readability and the ability to reason about code is almost always more important than how easy it is to test. One of the main points of TDD is to get you to easy to read about code by making constant refactoring part of your cycle.
4. With the PeopleController, the kind of mocking he describes is absolutely anathema to TDD. TDD is the red->green->refactor cycle. The “refactor” part of that cycle is both the most important part of that cycle and the part that most often gets ignored by people who don’t understand TDD. If you mock in the way that he describes, it is impossible to refactor. Therefor, a person doing that can’t possibly be doing TDD. They might be doing “test first,” but they aren’t doing TDD.
5. “Most Unit Testing is Waste” - The problem with this quote and everything DHH says about it is that there is an inherent assumption that what he thinks “unit testing” means is the same as what everyone else thinks “unit testing” means. Some people have gotten the idea that “isolating the code under test” means that you mock everything that you test the function a code is in and either inject or mock everything related to that function. If that is the definition for “unit test,” then TDD isn’t and never was about unit tests, because that sort of test prevents you from refactoring, which means that you are prevented from doing TDD. The TDD idea of “isolating the code under test” simply means that you are just testing one piece of logic and have controlled everything else. You could be running a test through a Rails controller that hits a service that hits another service that hits a model to find the piece of logic it’s testing, and so long as everything else is controlled and you’re just testing that one bit of logic, that’s a TDD unit test. Is TDD focused on the unit? That depends entirely on how you define unit.
6. He repeatedly equates TDD with “test first.” That’s like equating mammals with animals, pointing at a fish, and saying, “that’s a mammal, and it has no fur, so mammals aren’t real.”
Ultimately, the type of people that DHH thinks are proponents of TDD aren’t practicing TDD at all. You might think that this is a “No true Scotsman” argument, but it isn’t. TDD is defined by the “red/green/refactor” cycle, and these people are writing tests that make refactoring (changing your code without changing your tests) completely impossible.
I got 40 minutes in before I gave up. This would be such a great presentation is he could have just focused on the concepts he was talking about and not try to turn them into criticisms of TDD that actually have nothing to do with TDD.
Came back for the other 20 minutes!
"Unless you're doing tests first, you're not a professional."
The quality that makes one a professional is constantly refactoring things. Refactoring is the heart and soul of TDD (actual TDD, not merely "test first"). Constant refactoring is necessary for clean code, and great tests are necessary for constant refactoring. TDD is not necessarily the only way to get there, but the TDD process imprints thorough testing and constant refactoring into your bones.
The problem with Active Record is that mixing concerns encourages people to write code that is harder to read. Most of the "rules" he's bashing here are rules for writing code that's more clear and readable. The problem is that while our jobs might indeed be more equivalent to writing, lots of devs aren't very good writers, so lots of devs will follow the rules religiously without understanding their purpose. If they're fussing at you about this, then yeah, it's annoying. But those sorts of people are there and annoying in all aspects of life. It doesn't mean the guidelines are bad.
Everything he says about "drafts" at the end is exactly what TDD is all about. I could actually open a presentation about TDD with almost exactly what he said (except to forget about TDD)