Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Artur's presentation at RubyC-2018

Railsware

June 03, 2018
Tweet

More Decks by Railsware

Other Decks in Technology

Transcript

  1. Image: https://www.washingtontimes.com Not available for 6 hours +6500 calls discarded

    11 mln people affected Reason : counter overflow 911 outage in USA
  2. “Software engineers don’t understand the problem they’re trying to solve,

    and don’t care to. Nancy Leveson, Software-safety expert, MIT
  3. “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
  4. 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
  5. “I don't know how to do this, so let's do

    it the simplest way and we'll figure out.
  6. We have $50k of tech debt We embraced it to

    learn a lot through experiments over the years Image: http://xarxanet.org
  7. Have as much vision as you can Gather product group

    Short-term / mid-term / long-term Based on current knowledge For each component
  8. “If I had asked people what they wanted, they would

    have said: faster horses... Henry Ford
  9. “Good code (...) provides highest value for the lowest cost.

    99 Bottles of OOP by Sandi Metz and Katrina Owen
  10. Assess tech compliance to vision Gather tech leadership group Look

    at architecture for each feature component See how it complies / supports vision
  11. Improve structure for mid-term vision Clean up after experiments Reflect

    acquired knowledge Image: https://www.bonsaiempire.com
  12. 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
  13. 99 Bottles of OOP by S. Metz & K. Owen

    https://www.sandimetz.com/99bottles/
  14. 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
  15. “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
  16. 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