Stop using development mode

Rails development mode is easy, useful and fast: we can spin up an app, edit its source, hit reload in a browser and see the result of our changes. But what effect does this workflow have on our code, and does it really help us? In this talk I look at the dark side of development mode — where it falls down, what it does wrong, and how it ultimately encourages us to develop software in the wrong way — and suggest an alternative way of working which avoids these disadvantages.

Given at Railsberry (http://railsberry.com/). There's a video of this talk at http://youtu.be/TQrEKwb5lR0.

Transcript

1. Stop using
   development mode.
   by @tomstuart, at Railsberry, in Kraków, on 2012-04-20.
   

   View Slide

2. How to develop a
   Rails application:
   

   View Slide

3. RAILS_ENV=development
   

   View Slide

4. config/environments/
   development.rb:
   config.cache_classes = false
   

   View Slide

5. $ rails server
   

   View Slide

6. View Slide

7. View Slide

8. View Slide

9. View Slide

10. View Slide

11. View Slide

12. View Slide

13. View Slide

14. View Slide

15. View Slide

16. View Slide

17. View Slide

18. (That was 2005.)
    

    View Slide

19. Development mode
    is what first got me
    excited about Rails.
    

    View Slide

20. Reload-driven
    development ™
    

    View Slide

21. What’s wrong with
    this methodology?
    

    View Slide

22. cowboy programming
    testless programming
    inside-out programming
    it encourages:
    

    View Slide

23. Cowboy
    programming
    

    View Slide

24. programming before
    thinking
    pressing reload until it
    looks like it’s working
    writing the code you want
    to write
    

    View Slide

25. Testless
    programming
    

    View Slide

26. why write tests when you can
    press reload?
    

    View Slide

27. PRESSING
    RELOAD
    DOESN’T
    SCALE
    

    View Slide

28. why write tests when you can
    press reload?
    the app works! now write tests
    so you don’t feel guilty
    the app broke! now write tests
    so it doesn’t break again
    

    View Slide

29. THE
    DEFINITION
    OF
    WORKING
    IS THAT THE
    TESTS
    PASS
    

    View Slide

30. Inside-out
    programming
    

    View Slide

31. write a migration
    write a model
    write a controller
    write a template
    write a route
    press reload
    

    View Slide

32. database.
    

    View Slide

33. database.
    model.
    

    View Slide

34. database.
    model.
    controller.
    

    View Slide

35. database.
    model.
    controller.
    template.
    

    View Slide

36. database.
    model.
    controller.
    template.
    route.
    user.
    

    View Slide

37. You build each layer
    before you’ve built
    the layer that uses it.
    

    View Slide

38. You are imagining
    what the next layer
    will need this one
    to do.
    

    View Slide

39. If you love
    imagining things
    that much,
    

    View Slide

40. move to Los Angeles
    

    View Slide

41. and become a Scientologist.
    

    View Slide

42. Development mode doesn’t let
    you see anything working until
    you’ve completed a full vertical
    slice through the application.
    

    View Slide

43. This makes it easier
    to write badly
    designed code.
    

    View Slide

44. If Rails has a
    development mode,
    shouldn’t I use it?
    

    View Slide

45. View Slide

46. What’s a
    “web framework”?
    

    View Slide

47. “A collection of
    libraries, utilities and
    conventions to make
    web application
    development easier.”
    

    View Slide

48. You are right
    and good.
    

    View Slide

49. “A note from my
    mother excusing me
    from responsibility
    for every decision.”
    

    View Slide

50. YOUR FAULT
    YOU ARE WRONG
    AND
    BAD
    EVERYTHING
    IS
    

    View Slide

51. Rails is software.
    It doesn’t care
    about you.
    

    View Slide

52. Be mindful.
    Use judgement.
    

    View Slide

53. There is a better way.
    

    View Slide

54. Two related ideas:
    

    View Slide

55. 1. Work outside-in.
    

    View Slide

56. Start by writing
    an acceptance test
    to explain
    the ultimate goal.
    

    View Slide

57. (An automated one.)
    

    View Slide

58. Drill down into the
    application by writing
    unit tests to set
    intermediate goals.
    

    View Slide

59. Make progress towards
    the ultimate goal
    by getting unit tests to pass,
    not by pressing reload.
    

    View Slide

60. Reach the ultimate goal
    by getting the acceptance
    test to pass,
    not by pressing reload.
    

    View Slide

61. (During development,
    your primary clients
    are automated tests,
    not web browsers.)
    

    View Slide

62. How is this possible?
    How can you test
    the controller before
    writing the model?
    

    View Slide

63. 2. Use mocking.
    

    View Slide

64. Ruby is inspired by
    Smalltalk.
    

    View Slide

65. Smalltalk says:
    a program is
    a network of
    collaborating objects.
    

    View Slide

66. View Slide

67. Reboot your brain
    to think in terms of
    object collaboration.
    

    View Slide

68. Drive out
    the design of objects
    using mocking,
    not guessing.
    

    View Slide

69. mock
    these
    unit test
    this
    

    View Slide

70. You can implement
    an object before its
    collaborators exist.
    

    View Slide

71. By the time you start
    implementing them,
    you’ll already know
    what they need to do.
    

    View Slide

72. It’s not about
    coverage, it’s about
    driving your design
    directly at every level.
    

    View Slide

73. The only limitation is
    your acceptance tests.
    

    View Slide

74. Some automated tests
    are too hard,
    or impossible,
    to write.
    

    View Slide

75. Fine:
    use development
    mode to run those
    acceptance tests with
    your eyes and brain.
    

    View Slide

76. Why work this way?
    

    View Slide

77. Better design.
    Better code.
    Less pressing reload.
    Faster tests.
    

    View Slide

78. It is possible to build a
    web application
    without opening a
    web browser.
    

    View Slide

79. “Do I need to use
    development mode?”
    

    View Slide

80. In practice:
    

    View Slide

81. growing-object-oriented-software.com
    

    View Slide

82. pragprog.com/book/achbd/the-rspec-book
    

    View Slide

83. Thank you.
    @tomstuart / tom@experthuman.com / computationbook.com
    

    View Slide