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


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

  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:
  3. Your first lines of code...

  4. Your first mistakes...

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

    new” “
  6. Screwing things up...

  7. Release Failure Prod Dev

  8. Mom to the rescue...

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

  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
  11. Code Product Process Types of mistakes

  12. Product Mistakes Products which have failed or made mistakes related

    to design and ideas.
  13. FitSpoon

  14. Throne Master

  15. Process Mistakes This includes any process related in the cycle

    of software development: Releasing, hiring, management, etc.
  16. Coding Mistakes Main bad practices we make as engineers and

    hints on how to solve them.
  17. Code must be self-explanatory READABLE CODE 1

  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 */
  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: */
  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); }
  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.
  22. Code written in ... interface ElokuvaArkisto { fun elokuvat(): Either<Vika,

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

    List<Movie>> class Network @Inject constructor(private val networkHandler: NetworkHandler, private val service: MoviesService) : MoviesRepository { override fun movies(): Either<Failure, List<Movie>> { return when (networkHandler.isConnected) { true -> request(service.movies(), { { it.toMovie() } }, emptyList()) false -> Left(NetworkConnection()) } } fun request() { ... } } }
  24. “Always code as if the guy who ends up maintaining

    your code will be a violent psychopath who knows where you live.” “
  25. Please only for learning purpose REINVENTING THE WHEEL 2

  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
  27. Naming is always complicated NAMING THINGS 3

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

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

    LegacyJsonParser { ... }
  30. Detecting anti patterns is key in any codebase ANTI PATTERNS

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

    many more...
  32. OOP and FP principles Design principles intended to make software

    designs more understandable, flexible and maintainable.
  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
  34. Patterns and code consistency

  35. The boy scout rule

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

  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.
  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
  39. Zero Bugs Application

  40. “Zero-Bug does not mean bug-free code production, it means striving

    to eradicate all known bugs”
  41. Screwing it up... ...and recovery

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

  43. Share your experiences!

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

  45. You can find me at: Twitter: @fernando_cejas Github: @android10 Blog: Any questions? Thanks!
  46. Vector Icons by Matthew Skiles Presentation template designed by Slidesmash

    Photographs by Special thanks to all people who made and share these awesome resources for free: Credits
  47. This presentation uses the following typographies and colors: Colors used

    Free Fonts used: Presentation Design