RailsConf 2014 – Keynote: Writing Software by David Heinemeier Hansson

ABOUT THE AUTHOR

Lilly

Producer, Blogger, Television Host, Green building lover, Queen of the Forest. Pour yourself a drink, put on some lipstick, and pull yourself together.

( 36 )
  • Tiago Dias

    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.

    Reply
  • Tuomas Hietanen

    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).

    Reply
  • John Broderick

    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.

    Reply
  • zardthebard

    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.

    Reply
  • Juan

    DHH always making us rethink. Awesome.

    Reply
  • vjunloc1

    Fucking awesome, this is what i always try to explain to people, DHH has hit bullseye 

    Reply
  • Piotr Kaluza

    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.

    Reply
  • efrenUtube

    I want to hear the point of view of guys who are against the points of DHH   BUT  are actually as successful as him. Please.

    Reply
  • mandokir

    tl;dr: software is art.

    Reply
  • Brandon Kindred

    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. 

    Reply
  • fuu

    Nice talk, however TDD can be simple, see: https://gist.github.com/saxxi/72ebe2929c8758f33a11

    Reply
  • Wilker Lucio

    DHH telling the world how to complect software.

    Reply
  • Ben Nelson

    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 😉

    http://www.openculture.com/2014/07/faulkners-review-of-ernest-hemingways-the-old-man-and-the-sea.html

    Reply
  • yan kumar

    thanks for sharing Confreaks

    Reply
  • Chris Dillon

    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?

    Reply
  • soheil yasrebi

    I can now see why he flunked math: "I don't care if the units work, I care if the system works!" 

    Reply
  • superharryboy

    tl;dr TDD and patterns are good as long as you don't mentally masturbate with them.

    Reply
  • Alberto Salvia Novella

    Unit testing everything is good as long it's done simple and after the coding.

    Reply
  • toketeeman1016

    I came independently to many of the same conclusions as Hansson approximately 4-5 years ago, and I am gratified that big guns as Hansson and Coplien have taken up the fight against these insidious testing fads. Thus, since that time, I have refused all interviews with companies that require TDD in their software development process. I know stupidity when I see it.

    Reply
  • EldanSai

    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.

    Reply
  • Dev Munchies

    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.

    Reply
  • Viorel Iosub

    A

    Reply
  • Jon Keskitalo

    'TDD is the most successful software diet of all time' lol

    Reply
  • Clay Shentrup

    Look at the Rails source. Just look at it. It makes this whole talk seem so strange.

    Reply
  • supbrotv

    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.

    Reply
  • Ron Clabo

    Testing code is good and it’s always been an important part of delivering quality software. Whether that testing is done by developers, a QA team, or others, it’s critical to do and often it’s wise to have multiple stages of testing (e.g. logic testing vs. usability testing). While I’m not a fan of using profanity to communicate, I believe that DHH makes some great points worth considering.

    I have a degree in Computer Science and have been creating software for several decades and I agree with DHH’s notion that writing code is not just about science it’s also about art. Personally, my goal is to write elegant code that is easy for others to understand and I find that this leads to reducing maintenance costs. Sometimes that “other” person maintaining the code is me years later and in such situations I’m even more grateful that readability was a priority during the initial writing of the software.  🙂

    My takeaway was that DHH believes that testability shouldn’t be elevated above code clarity, and I tend to agree. I think he is saying that we need to be careful how much indirection we inject into our code bases because indirection and abstractions can reduce clarity. Of course this doesn’t mean that all indirection or all abstraction is bad, far from it. Both are great tools for the right situations.

    But if in the search for improved testability we find ourselves writing code that is full of indirection and abstraction, such that it makes the code far harder to comprehend, maybe we should ask ourselves if we are making the right design tradeoff? In such a case, it’s quite possible that the intuitive design of the software has been altered so much to accommodate testability that it’s maintainability has actually been reduced. The first step to maintaining any software is to comprehend it. :-)

    Reply
  • theodopoulos

    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.

    Reply
  • Sérgio Toledo

    Very good points. He thinks "Outside the box".

    Reply
  • spenkicro

    HERETIC!

    Reply
  • Sam Liao

    This speaks exactly what I think about TDD and first priority of writing code.

    Reply
  • nazar k

    it is possible to test pretty whole system with capybara feature tests

    Reply
  • SuperGrimmy

    He was at "The Party' in Denmark, not "The Gathering" 😀

    Reply
  • CrazyHorseInvincible

    "DHH is the Fox News of Ruby." After watching this, I understand this quote completely.

    Reply
  • Colin Kiama

    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 🙂

    Reply
  • Randall Mitchell

    "Empirical truths, blah blah blah, we have laws, blah blah blah". 18 mins in and so far, I think I like this guy.

    Reply
  • Ragavendra Nagraj

    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 …..

    Reply

LEAVE A COMMENT

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>