Don't Aim for Reusability

Transcript

1. DON’T AIM FOR REUSABILITY … and what to aim for instead
2. ONCE UPON
 A TIME, FAR FAR AWAY… intro
3. “ Investing effort to make the code so smart / perfect / generic / etc. that it’ll pay off many times in the future. AIMING FOR REUSABILITY IS …
4. 8 MISTAKEN BELIEFS about reusability
5. MISTAKEN BELIEF #1 I will save time in
 the long run
6. https://xkcd.com/1319/
7. I WILL SAVE TIME IN THE LONG RUN ➤ You’re underestimating development work and overestimating manual work ➤ You’re neglecting maintenance effort
8. MISTAKEN BELIEF #2 It will also need to handle X
9. IT WILL ALSO NEED TO HANDLE X ➤ Feature creep is inevitable if you build for the unknown ➤ “Best practices” from Google, Facebook, …
10. MISTAKEN BELIEF #3 I’m a genius, a hack won’t do
11. I’M A GENIUS, A HACK WON’T DO ➤ Social pressure - we want to appear smart ➤ It’s fun to write complex stuff
12. MISTAKEN BELIEF #4 Someone will remember to reuse my code
13. “ How many lines of code are rotting in your lib folder?
14. SOMEONE WILL REMEMBER TO REUSE MY CODE ➤ People come and go ➤ Documentation needs to be written and read
15. MISTAKEN BELIEF #5 I’ll want to reuse what I am writing now
16. LOOKING AT OLD CODE … Oh interesting. That’s really weird … What on earth?! WHO WROTE THIS?! git blame Oops, that was me ….
17. I’LL WANT TO REUSE WHAT I AM WRITING NOW ➤ No matter how good you are, your code will look bad to you tomorrow ➤ Newer tech might solve the problem much easier in the future
18. MISTAKEN BELIEF #6 Reusing is faster than
 writing from scratch
19. REUSING IS FASTER THAN WRITING FROM SCRATCH ➤ Why is it so much faster to do greenfield development? ➤ Understanding existing code takes time
20. MISTAKEN BELIEF #7 Everything is an instance of some abstract concept
21. “ Coincidence is a lot more common than the human brain thinks it is.
 There might not actually be a general case,
 even if you see it clear as day. - Mattias Petter Johansson https://www.quora.com/Should-you-write-reusable-code-or-write-code-that-fits-the-use-case-Whenever-I-start-to- design-my-classes-I-start-thinking-about-re-usability-and-then-I-start-creating-more-classes-Whats-the-right-way- of-designing-classes
22. MISTAKEN BELIEF #8 I can predict the future
23. “ You will get it wrong.
24. I CAN PREDICT THE FUTURE ➤ Good abstractions need many examples ➤ Businesses change ➤ Product Managers People change their requirements minds
25. “ We should be less fearful of writing code well suited to the requirements, but with little regard for reuse potential, and then rewrite a better version from scratch the next time. - Tony Davis https://www.red-gate.com/simple-talk/blogs/whats-the-use-of-code-reuse/
26. WHAT IF WE DON’T AIM FOR REUSE BUT FOR DELETION?
27. I WILL SAVE TIME
 IN THE LONG RUN YOU TAKE THE SHORTEST
 WAY TO DELIVERY
28. IT WILL ALSO NEED TO HANDLE X YOU BUILD ONLY WHAT IS NEEDED
29. I’M A GENIUS, A HACK WON’T DO YOU CARE MORE ABOUT BUSINESS IMPACT THAN YOUR EGO
30. SOMEONE WILL REMEMBER TO REUSE MY CODE NO-ONE HAS TO KNOW ABOUT YOUR CODE
31. I’LL WANT TO REUSE WHAT I AM WRITING NOW YOU CAN IGNORE YOUR STUPID OLD CODE
32. REUSING IS FASTER THAN WRITING FROM SCRATCH YOU DON’T HAVE TO FIT NEW CODE INTO OLD STRUCTURES
33. EVERYTHING IS AN INSTANCE OF SOME ABSTRACT CONCEPT YOU WON’T HAVE A GENERIC SYSTEM USED ONLY ONCE
34. I CAN PREDICT THE FUTURE YOU DON’T WASTE TIME WITH WRONG ASSUMPTIONS
35. AIMING FOR DELETION leads to quick results & maintainability
36. AIMING FOR DELETION LEADS TO MAINTAINABILITY Time Cost of Change Design Done Maintenance Wall of Unmaintainability Boehm’s curve
37. “ No code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code. No code is easier to understand than no code. - Mike Perham http://www.mikeperham.com/2016/02/09/kill-your-dependencies/ AIMING FOR DELETION LEADS TO MAINTAINABILITY
38. WRITING CODE THAT IS EASY TO DELETE A few ideas
39. I. SHIFTING MINDSET (Hobby) (Business) generic code that can do everything specific code that does exactly what is needed vs
40. II. DRY IS A TRAP • DRY is one of the most popular principles in the Ruby world • DRY is dangerous • Don’t fear code duplication - it’s required for the right abstraction
41. III. DECREASE IMPACT • Obviously, globals are the hardest things to delete • Callbacks and validations need to be interaction specific • Let presenters wrap views • Find the smallest scope, the loosest connection
42. AIM FOR DELETION
43. THANK YOU Questions?