Breaking Backwards Compatibility: The easy way

Say you have this piece of software that many people use. One day, you wake up and you have the urge to make them suffer. Well, there’s no better way to do so than breaking the software they’re using.

In this talk, I’ll walk you through very good ways to do so by showing examples taken from experience - because experience is the only thing that matters (TM) - so that you’ll be able, by the time this talk ends, to do the same to your users.

(P.S: If you’ve a kinder hearth, you can also do the exact opposite of what I’ll say and keep your users happy.)

Transcript

1. Breaking Backwards
   Compatibility
   

   View Slide

2. Breaking Backwards
   Compatibility
   Easy Way
   

   View Slide

3. View Slide

4. For attending
   Still here
   feel free to interrupt
   @flaper87
   flavio@redhat.com
   

   View Slide

5. Backwards Compatible...
   [...] If products designed for the
   new standard can receive, read,
   view or play older standards or
   formats, then the product is said
   to be backward-compatible[...]
   http://en.wikipedia.org/wiki/Backward_compatibility
   

   View Slide

6. Don’t use versioning
   

   View Slide

7. Don’t deprecate things
   

   View Slide

8. Inconsistency FTW
   

   View Slide

9. Assume you’re the user
   

   View Slide

10. Keep everything public
    

    View Slide

11. Keep users in the dark
    

    View Slide

12. On a more
    serious note
    

    View Slide

13. You’ve been
    that hacker
    

    View Slide

14. Why Does it
    matter?
    It’ll help you save TIME but
    not only that. It’ll also help
    you save MONEY and it does
    not end there. It also helps
    saving KITTENS.
    

    View Slide

15. Version
    Don’t re-invent it
    Cross-platform
    Cross-language
    Semver (?)
    Cap versions
    

    View Slide

16. communicate
    Let them know what’s
    going away
    Do that at least 1 cycle
    in advance
    Have a well defined
    release cycle
    

    View Slide

17. Consistent API
    Helps users migrating
    over new versions
    Helps you maintaining
    your software
    Design by contract
    

    View Slide

18. Privacy Rules
    Private by default
    Don’t expose internals,
    commons or utilities
    If it’s public, you can’t
    assume it’s not being
    used
    

    View Slide

19. Stability Attributes
    Stable shouldn’t break
    Unstable can break
    Be explicit about your
    software stability
    

    View Slide

20. Testiing
    Unit and functional
    tests are taken for
    granted
    Do integration tests
    If possible, run cross-
    version, integration tests
    

    View Slide

21. Questions?
    

    View Slide