$30 off During Our Annual Pro Sale. View Details »

The art of coding disasters and failures

The art of coding disasters and failures

Software engineering and technology is about constant evolution, which mainly involves continuous improvement.
And in order to achieve it, there is long path ahead of us, which many times is not easy to follow up.
Jump onboard in this journey about common (or not) software engineering disasters, failures and mistakes and how we can get the most out of those lessons in order to learn and write/develop better software.

Fernando Cejas

April 24, 2018
Tweet

More Decks by Fernando Cejas

Other Decks in Programming

Transcript

  1. by @fernando_cejas
    The art of coding
    disasters and
    failures

    View Slide

  2. I am here because I love to share
    experiences and disasters I
    have made in my professional
    life.
    Hello!
    I’m Fernando Cejas
    You can find me:
    ● Twitter: @fernando_cejas
    ● Github: android10
    ● Blog:
    www.fernandocejas.com

    View Slide

  3. Your first lines of code...

    View Slide

  4. Your first mistakes...

    View Slide

  5. “A person who never
    made a mistake never
    tried anything new”

    View Slide

  6. Screwing things up...

    View Slide

  7. Release Failure
    Prod
    Dev

    View Slide

  8. Mom to the rescue...

    View Slide

  9. May the force of
    FAILURE be with you...

    View Slide

  10. Fact: Our
    Software is
    terrible!!!
    And that doesn’t make it special.
    All software is terrible, and yes, we know it is
    definitely TRUE

    View Slide

  11. Code
    Product Process
    Types of mistakes

    View Slide

  12. Product Mistakes
    Products which have failed or made mistakes related to
    design and ideas.

    View Slide

  13. FitSpoon

    View Slide

  14. Throne Master

    View Slide

  15. Process Mistakes
    This includes any process related in the cycle of software
    development: Releasing, hiring, management, etc.

    View Slide

  16. Coding Mistakes
    Main bad practices we make as engineers and hints on how
    to solve them.

    View Slide

  17. Code must be self-explanatory
    READABLE CODE
    1

    View Slide

  18. Comments do not work
    They are always outdated.
    Rename and refactor.
    /**
    * Dear maintainer:
    *
    * Once you are done trying to 'optimize' this routine,
    * and have realized what a terrible mistake that was,
    * please increment the following counter as a warning
    * to the next guy:
    *
    * total_hours_wasted_here = 42
    */

    View Slide

  19. Comments do not work
    They are always outdated.
    Rename and refactor.
    /**
    * When I wrote this, only God and I understood what I was doing
    * Now, God only knows
    */
    /**
    * Before modifying this code, please call me: [email protected]
    */

    View Slide

  20. public void path(Node myNode, Key k) {
    Node h = myNode.find(key)
    if (k.compareTo(h.key) < 0) {
    if (!isRed(h.left) && !isRed(h.left.left)) {
    h = moveRedLeft(h);
    h.left = delete(h.left, k);
    }
    } else {
    if (isRed(h.left)) h = rotateRight(h);
    if (k.compareTo(h.key) == 0 && (h.right == null)) h = null;
    if (!isRed(h.right) && !isRed(h.right.left)) h = moveRedRight(h);
    if (k.compareTo(h.key) == 0) {
    Node x = min(h.right);
    h.key = x.key;
    h.val = x.val;
    h.right = deleteMin(h.right);
    } else {
    h.right = delete(h.right, k);
    }
    }
    balance(h);
    }

    View Slide

  21. Hide complexity
    public void findPath(Node fromNode, Key key) {
    Node node = myNode.find(key)
    //some logic
    deleteNode(node)
    }
    private Node deleteNode(Node node, Key key) {
    if (key.compareTo(node.key) < 0) {
    if (!isRed(node.left) && !isRed(node.left.left))
    node = moveRedLeft(node);
    node.left = delete(node.left, key);
    }
    ...
    return balance(node);
    }
    Refactoring is our friend.

    View Slide

  22. Code written in ...
    interface ElokuvaArkisto {
    fun elokuvat(): Either>
    class Verkko
    @Inject constructor(private val verkkoKäsittelijä: VerkkoKäsittelijä,
    private val palvelu: ElokuvaPalvelu) : ElokuvaArkisto {
    override fun elokuvat(): Either> {
    return when (verkkoKäsittelijä.onYhdistetty) {
    true -> request(palvelu.elokuvat(), { it.map { it.elokuvaan() } }, emptyList())
    false -> Left(Verkkoyhteys())
    }
    }
    fun pyyntö() { ... }
    }
    }

    View Slide

  23. Code written in english
    interface MoviesRepository {
    fun movies(): Either>
    class Network
    @Inject constructor(private val networkHandler: NetworkHandler,
    private val service: MoviesService) : MoviesRepository {
    override fun movies(): Either> {
    return when (networkHandler.isConnected) {
    true -> request(service.movies(), { it.map { it.toMovie() } }, emptyList())
    false -> Left(NetworkConnection())
    }
    }
    fun request() { ... }
    }
    }

    View Slide

  24. “Always code as if the guy
    who ends up maintaining
    your code will be a violent
    psychopath who knows
    where you live.”

    View Slide

  25. Please only for learning purpose
    REINVENTING THE WHEEL
    2

    View Slide

  26. Reinventing the wheel
    Only for learning purpose.
    Once I worked on a chat built in assembler...
    WinZip WinRAR UltraZip
    180 files total size 2387 Kb 2387 Kb 2387 Kb
    File compressed size 1241 Kb 1169 Kb 2362 Kb
    Total Compression ratio 48% 51% 1%
    Time elapsed 32 seconds 37 seconds 199 seconds

    View Slide

  27. Naming is always complicated
    NAMING THINGS
    3

    View Slide

  28. Naming is complicated
    Please refactor.
    @Deprecated Annotation.

    View Slide

  29. Naming is complicated
    Please refactor.
    @Deprecated Annotation.
    @Deprecated("Use JsonParser")
    class LegacyJsonParser {
    ...
    }

    View Slide

  30. Detecting anti patterns is key in any codebase
    ANTI PATTERNS
    4

    View Slide

  31. Anti patterns detection
    OOP God classes and Singletons.
    Lava antipattern, many more...

    View Slide

  32. OOP and FP principles
    Design principles intended to make software designs more
    understandable, flexible and maintainable.

    View Slide

  33. Most FP still have structs. Specifying
    the smallest set of data required by a
    function is still good practice.
    Requiring the least specific interface
    to the data is also a good practice.
    Abiding by some interface contract
    is just as good in functional
    programming as in object oriented.
    If a sort function takes a
    comparator, then you would expect
    the '0 is equals, less than provides
    negative results, greater than
    positive results' behavior.
    'Only do one thing' was taken from
    imperative programming in the first
    place. Having small, focused
    functions is good.
    Specifying parameters to a function
    (or a higher order function to
    retrieve them) rather than hard
    coding the function to go get some
    value is just as good in FP as in
    object oriented.
    Allowing you to change behaviors
    without modifying code is good. FP
    uses higher order functions more
    than inheritance, but the principle
    holds.
    Programming principles
    SRP
    OCP
    LSP
    ISP
    DIP
    OOP and FP
    https://softwareengineering.stackexchange.com/questions/165356/equivalent-of-solid-principles-for-functional-programming

    View Slide

  34. Patterns and code
    consistency

    View Slide

  35. The boy scout
    rule

    View Slide

  36. CODE is communication
    between people
    (that incidentally runs on a computer)

    View Slide

  37. Extra Ball
    Good practices at PROCESS level which can help you to
    detect and avoid failures and mistakes in order to write
    higher quality software.

    View Slide

  38. Always use the best tool for
    the right job.
    Best Tool
    A couple of extra eyes always
    add quality to the code.
    Pair
    Programming
    You do not have to do 100%
    TDD but is one more tool in
    your toolbox.
    TDD
    Communication and
    knowledge sharing are keys
    in any project.
    Work as a
    team
    It is key to count on an mature
    CI automated and easier
    releasing and building.
    CI Pipeline
    Techniques like refactoring help
    to have a healthy codebase.
    Continuous
    Improvement
    Good practices

    View Slide

  39. Zero Bugs
    Application

    View Slide

  40. “Zero-Bug does not mean bug-free
    code production, it means striving to
    eradicate all known bugs”

    View Slide

  41. Screwing it up...
    ...and recovery

    View Slide

  42. Learn out of mistakes!!!
    Have a Hero!!!
    TEST YOUR SOFTWARE!

    View Slide

  43. Share your experiences!

    View Slide

  44. May the force of
    FAILURE be with you...

    View Slide

  45. You can find me at:
    Twitter: @fernando_cejas
    Github: @android10
    Blog: https://www.fernandocejas.com
    Any questions?
    Thanks!

    View Slide

  46. Vector Icons by Matthew Skiles
    Presentation template designed by Slidesmash
    Photographs by pexels.com
    Special thanks to all people who made and share
    these awesome resources for free:
    Credits

    View Slide

  47. This presentation uses the following typographies and colors:
    Colors used
    Free Fonts used:
    https://www.fontsquirrel.com/fonts/montserrat
    https://www.fontsquirrel.com/fonts/open-sans
    Presentation Design

    View Slide