The Dilemma of Simplicity

Over the years we've learned to pay attention to the importance of a number of highly desirable qualities in software: readability, maintainability, adaptation to change. We've accepted these values as good and actively pursue them yet we consistently ignore what is probably the best method of achieving these qualities, it's staring us right in the face now.

Slowly but steadily the philosophy of embracing simplicity in software design by carefully calculating and minimizing unnecessary complexity is gaining traction in our community, and for a good reason: it organically pushes us to the best software practices we all know and love, it both embraces all the core principles the ruby community has developed over the years while rejecting many of the common practices we carry based on inertia but which directly contradict these values.

In this talk I explore my journey on this shift in perspective from certain fragments of our community and how thinking about simplicity as one of our core values can push us to be better developers while producing better quality of software. We don't need our crutches anymore, let's drop them together!

Transcript

1. Dilemma Simplicity. The of
2. @poteland ! "
4. Thanks AP.Rb!
5. Sorry!
7. Simplicity
8. Act I of needs and solutions
9. Quality
10. User Experience
11. Reliability
12. Security
13. Maintainability
14. Performance
15. They Matter
16. Act II of hype and definitions
17. Buzzword
18. Definition
20. Definition
21. Not Trivial :\
22. @tiodante
23. Perception
24. class SessionsController < ApplicationController! def new! ! ! ! render :new! end! end! @model = FictionalModel.last
27. Perception (again)
28. class SessionsController < ApplicationController! def new! ! ! ! render :new! end! end! @model = FictionalModel.last
29. `rake middleware`
30. class SessionsController < ApplicationController! def new! ! ! ! render :new! end! end! @model = FictionalModel.last
37. class SessionsController < ApplicationController! def new! ! ! ! render :new! end! end! @model = FictionalModel.last
39. Hidden complexity.
40. What if it breaks?
41. (╯°□°)╯︵ sʃıɐᴚ
42. Rewrite it in Node!
43. Still need a definition :(
44. CHEAT.
45. ★。★。★。★ ☆ 。☆。☆ ★。＼｜／。★ ¯\_(ツ)_/¯ ★。／｜＼。★ ☆ 。☆。☆ ★。★。★。★
46. When does complexity matter?
47. confront When you it.
48. Unix.
49. “Something that can be understood quickly”
50. Smaller Stack
51. Act III of life and choices.
52. How does this change anything?
53. What about the ISSUES?
54. User Experience uri = URI('http://example.com/index.html')! params = { :limit => 10, :page => 3 }! uri.query = URI.encode_www_form(params)! ! res = Net::HTTP.get_response(uri)! ! puts res.body if res.is_a (Net::HTTPSuccess)
55. User Experience payload = {'key1': 'value1', 'key2': 'value2'}! ! r = requests.get(! “http://httpbin.org/get",! params=payload! )! ! r.status_code
56. Intuitive
57. Understandable
58. Python
59. Reliability
60. 100 features = 1 bug
61. More features = More bugs
62. Less features = Less bugs
63. Bugs are unavoidable
64. Simple stack = Easier to fix.
65. Simple = (more) reliable.
66. Security
67. More features = More bugs
68. More features = More vulnerabilities
69. Rails.
70. Maintainability
71. Understand Rewrite
72. Simple to understand?
73. Simple to maintain.
74. Performance
75. Stuff = Time
76. More Stuff = More Time
77. Simpler to find bottlenecks.
78. Symptoms of Complexity.
79. Don’t focus on the symptoms.
80. Reduce complexity.
81. Strive for simplicity.
82. Everything else will follow.
83. Epilogue of winning a losing battle
84. @soveran
85. Features = Complexity
86. Tradeoffs
87. Make conscious choices.
88. Thank you!
90. Questions!
91. Resources