“What We Know We Don’t Know” or “Empirical Software Engineering”

https://www.hillelwayne.com/talks/what-we-know-we-dont-know/

• Video from goto; conference + plenty of links
• Do you believe that “small functions are better then large functions”?
• Are you more confidence in that ^^ or in the “vaccine help against flu”?
• We don’t have Empirical results for Software Engineering!!!
• Everything we know about SE is a believe!
• Empirical Software Engineering (ESE): test, observe, find out what is true, and what is just “feel good”
• Why?
  • I’m developer, I want to get better, I need to know what works and what just “feels good”
  • Financial. 10% of GDP: IT. If we are 1% inefficient => we set on fire GDP of Iceland every year.
  • To protect ourselves from Charismatic Leaders and Preditors. Charisma Driven Development should be stoped. SOLID? Agile? Scrum?
• What is “Better”? Cyclomatic Complexity? And how do you know it works?
  • Quantitative study - hard numbers and comparison
  • Qualitative study - Experiences, thoughts, actions
• “Effects of Clean Code on Understandability” https://www.duo.uio.no/bitstream/handle/10852/51127/master.pdf
  • “Clean Code” book by Robert Martin:
    • Meaningful Names
    • Funcdtions should do one thing
    • Functions should be small
    • Don’t repeat yourself
    • Single Responsibility Principle
    • Clean Tests (5 additional rules for tests)
  • Refactored code (Clean Code), two different groups worked on different code.
  • Clean Code doesn’t improve the time used to implement new functionality
  • Clean Code improves the time used to change current functionality
  • Clean Code does not improve the time used to find and solve a bug
• The best paper about it: “Fixing Faults in C and Java Source Code: Abbreviated vs Full-Word Identifier Names” http://www2.unibas.it/gscanniello/Giuseppe_Scanniello%40unibas/Home_files/TOSEM.pdf
  • employer_number vs emp_num
  • It doesn’t matter
  • Qualitative study: change of name -> change how people debug code
• FINDING DEFECTS
• Code Smells. “On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation”. https://link.springer.com/article/10.1007/s10664-017-9535-z
  • Code Smells definition.
  • 1. The most diffused smells are the one related to size and complexity (Long Method, Spaghetti Code)
  • 2. Classes affected by code smells tend to be more change- and fault-prone. High fault-proneness is evident for smells such as Massage Chain that are not highly diffused.
  • 3. Removing code smells is beneficial most of the times for the code change-proneness. Fault-proneness is not changed if code smells are removed/added.
• Conway’s Law. “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
• “THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY” https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf
• Complexity metrics -> “Beyond Lines of Code: Do we Need More Complexity Metrics?“
• “Simple Testing Can Prevent Most Critical Failures”
• PREVENTING DEFECTS
• TDD? Not sure. It increases the quality. Though, it increases the time used to write tests. What reduces the number of bugs?
• Pair Programming? Type Systems? Not sure either.
• Code Review DOES HELP. 60-80% bugs are found during Code Review. Code Quality, Knowledge Sharing, etc…
• Sleep deprivation, Stress, Overwork -> increase risks. Order of magnitude better code if everything is ok.
• 1 week of 2h sleep deprivation each day = 1 night sleep miss -> Half as productive.
  • You can’t detect that you work worse!
  • You can’t fix that except sleep more.
• “Crunch Makes Games Worse”. Games made during “Crunch” is worse on every metrics (including profitability)
• Sleep, Stress - social, organizational, not technical => is not discussed widely.