Artur Hebda "Code is not important...or is it?"

Artur's presentation at RubyC-2018

Transcript

1. Code is not important… Artur Hebda Railsware Labs or is it?
2. Context of code Product story Building vision Growing structure Pro t-d i n me k }
3. We’re not hired to just write code.
4. Image: https://www.washingtontimes.com Not available for 6 hours +6500 calls discarded 11 mln people affected Reason : counter overflow 911 outage in USA
5. “Software engineers don’t understand the problem they’re trying to solve, and don’t care to. Nancy Leveson, Software-safety expert, MIT
6. Code always exists within a product context.
7. Customers pay for the value product delivers to them.
8. “It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point. Joel Spolsky
9. We’re hired to build & ship products.
10. Context of code Product story Building vision Growing structure Pro t-d i n me k }
11. Motivation behind OrgMap What is going on?
12. Q : How it?
13. Q : How il s i on ?
14. Q : How su e?
15. Q : Wha t e t p e? +
16. + + +
17. Seems strange… right? We used existing services / hack our way through We leveraged product development through experiments We closed feature loops ... And eventually built our own product
18. “I don't know how to do this, so let's do it the simplest way and we'll figure out.
19. Image: http://www.freeimages.co.uk Experiment to build something people want.
20. We have $50k of tech debt We embraced it to learn a lot through experiments over the years Image: http://xarxanet.org
21. Context of code Product story Building vision Growing structure Pro t-d i n me k }
22. Building vision constantly
23. Image: http://www.orlandospencer.com Product is a never consistent set of features
24. Split product into feature components
25. Have as much vision as you can Gather product group Short-term / mid-term / long-term Based on current knowledge For each component
26. Short-term http://www.donsmaps.com/images29/middleearthlarg elargerstill.jpg Image: http://www.donsmaps.com
27. Make educated guess I think it would be good to do...
28. Validate hypothesis with experiments A C B D
29. Natural tendency to predict further direction A C B D E?
30. Refine vision A C B D Wrong Correct
31. A C B D Wrong Correct inflexibility Refine vision
32. Mid-term http://www.donsmaps.com/images29/middleearthlarg elargerstill.jpg Image: http://www.donsmaps.com
33. Customers ask for a feature I really need that.
34. “If I had asked people what they wanted, they would have said: faster horses... Henry Ford
35. Q : Res t u s em t ?
36. Combined features
37. Demo - measure what is changing I like it, but maybe if…
38. Long-term http://www.donsmaps.com/images29/middleearthlarg elargerstill.jpg Image: http://www.donsmaps.com
39. Actual customer validated stuff Usage ~ long-term
40. Context of code Product story Building vision Growing structure Pro t-d i n me k }
41. Grow supporting structure Image: https://www.autodesk.com
42. “Good code (...) provides highest value for the lowest cost. 99 Bottles of OOP by Sandi Metz and Katrina Owen
43. Assess tech compliance to vision Gather tech leadership group Look at architecture for each feature component See how it complies / supports vision
44. Increase code quality and structure rigidity as you head towards long-term
45. Build experimental structure for short-term vision Get answers Acquire knowledge Image: http://freeimages.com
46. Improve structure for mid-term vision Clean up after experiments Reflect acquired knowledge Image: https://www.bonsaiempire.com
47. Build rigid structure for long-term vision Image: https://www.maxpixel.net Stabilize and scale
48. Maintain reasonable code quality for everything Low quality will slow you down Code without tests is harder to refactor Automate code quality assessment Automate processes - CI & CD
49. 99 Bottles of OOP by S. Metz & K. Owen https://www.sandimetz.com/99bottles/
50. Practice thorough PR reviews Do self-review before asking someone else Assess what cannot be automated yet Review like you would have to continue working on that right away
51. Reduce tech debt for the vision one step at a time
52. What is tech debt? Not only TODO and FIXME Rem r i l il ?
53. Make tech debt transparent Image: http://stocksmasters.com
54. Prioritise tech debt 5.times { why? }
55. Handle tech debt from backlog
56. “Make the change easy (warning: this may be hard), then make the easy change. Kent Beck
57. Boy Scout Rule - now or later?
58. Do not refactor without vision
59. “You should not reach for abstractions (...) resist them until they absolutely insist upon being created. 99 Bottles of OOP by Sandi Metz and Katrina Owen
60. Give yourself enough flexibility
61. Have strategic discussions Rails? React?
62. Summary Code exists in a product context, hence supports it Use product vision as a guidance for code Prefer understandability and let abstractions emerge Address inflexibility where it matters
63. One more thing...
64. So… is code important or not?
65. So… is code important or not? As important as value it creates.
66. Thank you! Questions? Follow @railsware
67. Thank you! Questions? Follow @railsware
68. Thank you! Questions? Follow @railsware