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.

Transcript

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: www.fernandocejas.com
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: fcejas@gmail.com */
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.map { 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.map { 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 4
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 https://softwareengineering.stackexchange.com/questions/165356/equivalent-of-solid-principles-for-functional-programming
34. Patterns and code consistency
35. The boy scout rule
36. CODE is communication between people (that incidentally runs on a computer)
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: https://www.fernandocejas.com Any questions? Thanks!
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
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