Managing Success: We made it, now we're screwed

Life as a startup, whether a bootstrapped company or an experimental project within an enterprise, is hard. You have to struggle to earn success. Lean, pivots, minimal viable products, and other buzzwords all steps along this journey. The struggle makes the eventual success that much sweeter. But it can also lead to suboptimal code, confusing logic, and general friction to getting things done.

In this talk I'll discuss ways to identify areas of your Rails app improve and strategies for improving the quality over time. I'll share insights on managing several large Rails applications, the dangers of the single, monolithic, ball of mud Rails app, and what changes make the biggest impact.

Transcript

1. Managing Success
   We made it, now we're screwed
   

   View Slide

2. View Slide

3. View Slide

4. View Slide

5. View Slide

6. You == Pain
   

   View Slide

7. (NIH)
   Not Invented Here
   

   View Slide

8. Why?
   

   View Slide

9. Conway's Law
   

   View Slide

10. Organizations which design
    systems are constrained to
    produce designs which are
    copies of the communication
    structures of these
    organizations.
    - Melvin Conway
    

    View Slide

11. "Ruby is designed to make
    programmers happy."
    - Matz
    

    View Slide

12. #1 Problem?
    

    View Slide

13. Monolithic
    

    View Slide

14. Models
    

    View Slide

15. Testing
    

    View Slide

16. TDD != QA
    

    View Slide

17. Pain
    

    View Slide

18. Pain
    

    View Slide

19. Pain
    

    View Slide

20. Cost
    Time
    Cost per change
    (bugs, new features, etc)
    Non-TDD TDD
    

    View Slide

21. Models
    Controllers/Routes
    Views/Helpers
    Application
    In Browser
    Cost per test
    

    View Slide

22. Models
    Controllers/Routes
    Views/Helpers
    Application
    In Browser
    ROI per test
    

    View Slide

23. Monolithic
    Models
    

    View Slide

24. 2 Rules
    

    View Slide

25. 1) Delarative
    

    View Slide

26. 2) Level of
    Abstraction
    

    View Slide

27. 
    <% @article.tags.each do |tag| -%>
    <%= link_to "#{tag.name} (#{tag.articles.length})",
    tag_path(tag) %>
    <% end %>
    
    

    View Slide

28. 
    <% @article.tags.each do |tag| -%>
    <%= link_to "#{tag.name} (#{tag.article_count})",
    tag_path(tag) %>
    <% end %>
    
    

    View Slide

29. 
    <% @article.tags.each do |tag| -%>
    <%= link_to "#{tag.name} (#{tag.article_count})",
    tag_path(tag) %>
    <% end %>
    
    

    View Slide

30. class Tag < ActiveRecord::Base
    belongs_to :article
    def article_count
    self.articles.count
    end
    end
    

    View Slide

31. class Tag < ActiveRecord::Base
    belongs_to :article
    def article_count
    # Performance hack
    # faster than SELECT COUNT(*)
    self.articles.select(:id).count
    end
    end
    

    View Slide

32. Monolithic Views
    

    View Slide

33. <% if @course.available? &&
    @course.self_enrollment &&
    @course.open_enrollment &&
    (!@course_enrollment || !@course_enrollment.active?) &&
    !session["role_course_#{@course.id}"] %>
    <%= render :partial => "join_course", :object => @course %>
    <% elsif @course_enrollment &&
    @course_enrollment.self_enrolled &&
    @course_enrollment.active? &&
    (!session["role_course_#{@course.id}"]) %>
    <%= render :partial => "drop_course",
    :locals => { :course => @course,
    :enrollment => @course_enrollment } %>
    <% elsif temp_type = session["role_course_#{@course.id}"] %>
    ...
    <% end %>
    

    View Slide

34. Helpers
    

    View Slide

35. <% if can_join_course?(@course, @enrollment) %>
    <%= render :partial => "join_course", :object => @course %>
    <% elsif can_drop_course?(@course, @enrollment) %>
    <%= render :partial => "drop_course",
    :locals => { :course => @course,
    :enrollment => @course_enrollment } %>
    <% elsif temp_type = temp_permissions_to(@course) %>
    ...
    <% end %>
    

    View Slide

36. Presenters
    

    View Slide

37. module CourseHelper
    def can_join_course? course, enrollment
    course.available? &&
    course.self_enrollment &&
    course.open_enrollment &&
    (!enrollment || !enrollment.active?) &&
    !temp_permissions_to(course)
    end
    def can_drop_course? course, enrollment
    enrollment &&
    enrollment.self_enrolled &&
    enrollment.active? &&
    !temp_permissions_to(course)
    end
    def temp_permissions_to course
    session["role_course_#{course.id}"]
    end
    end
    

    View Slide

38. <% if @presenter.can_join_course? %>
    <%= render :partial => "join_course", :object => @presenter.course %>
    <% elsif @presenter.can_drop_course? %>
    <%= render :partial => "drop_course",
    :locals => { :course => @presenter.course,
    :enrollment => @presenter.enrollment } %>
    <% elsif @presenter.temp_permissions %>
    ...
    <% end %>
    

    View Slide

39. class CourseShowPresenter # this is a ViewModel, really
    attr_accessor :course, :enrollment, :current_user, :session
    def can_join_course?
    @course.available? &&
    @course.self_enrollment &&
    @course.open_enrollment &&
    (!@enrollment || !@enrollment.active?) &&
    !temp_permissions
    end
    def can_drop_course?
    @enrollment &&
    @enrollment.self_enrolled &&
    @enrollment.active? &&
    !temp_permissions
    end
    def temp_permissions
    @session["role_course_#{@course.id}"]
    end
    end
    

    View Slide

40. 1) Delarative
    

    View Slide

41. 2) Level of
    Abstraction
    

    View Slide

42. Monolithic Apps
    

    View Slide

43. Monolithic Apps
    

    View Slide

44. View Slide

45. What is code?
    

    View Slide

46. View Slide

47. “Underlying our approach to this
    subject is our conviction that
    “computer science” is not a science
    and that its significance has little to
    do with computers.
    ... The computer revolution is a
    revolution in the way we think and in
    the way we express what we think.
    

    View Slide

48. ... we want to establish the idea that
    a computer language is not just a
    way of getting a computer to
    perform operations but rather that it
    is a novel formal medium for
    expressing ideas about methodology.
    Thus, programs must be written for
    people to read, and only incidentally
    for machines to execute.
    

    View Slide

49. ... we believe that the essential
    material to be addressed by a subject
    at this level is not the syntax of
    particular programming-language
    constructs, nor clever algorithms for
    computing particular functions
    efficiently, nor even the mathematical
    analysis of algorithms and the
    foundations of computing, ...
    

    View Slide

50. but rather the techniques
    used to control the
    intellectual complexity of
    large software systems.”
    

    View Slide

51. but rather the techniques
    used to control the
    intellectual complexity of
    large software systems.”
    

    View Slide

52. Intellectual
    Complexity
    

    View Slide

53. Human
    Activity
    

    View Slide

54. View Slide

55. View Slide

56. “Often people, especially computer
    engineers, focus on the machines.
    They think, “By doing this, the
    machine will run faster. By doing this,
    the machine will run more
    effectively. By doing this, the machine
    will something something
    something.” They are focusing on
    machines...
    

    View Slide

57. But in fact we need to focus on
    humans, on how humans care about
    doing programming or operating the
    application of the machines. We are
    the masters. They are the slaves.”
    -Matz
    

    View Slide

58. The 80%?
    

    View Slide

59. View Slide

60. View Slide

61. View Slide

62. Thank you!
    

    View Slide

63. View Slide

64. HIRE ME!!!
    

    View Slide

65. HIRE ME!!!
    humanecode.com
    

    View Slide

66. HIRE ME!!!
    humanecode.com
    Questions?
    

    View Slide