Who

DRAFT

Code Health

5 August

How does one know if the code is any good? 

  • Static analysis? 
  • Test Coverage? 
  • “We’re doing the right things so the code must be good”? 
  • We’re doing agile
  • We value continued education
  • Our customers love it
  • They aren’t complaining

No, no, nope, definitely not. 

Some of those can certainly help, but not without major caveats and oversights.  For a complete picture, look no further than this list:

  1. Do all devs apply zen code principles when writing code and abstracting concepts? 

    Is the vast majority of code “zen”? 

  2. Do all devs understand and/or discuss the encapsulation and impact to the mental model of the code being added/changed/removed? 

    Do the vast majority of decisions favor simplifying the mental model and improving encapsulation? 

  3. Can the architecture, patterns, mental models, and code organization each be explained briefly with simple diagrams? 

    Without skipping important details or constantly thinking about complications and exceptions to the diagram? 

  4. Do developers do regular code read-throughs and improve the code afterwards? 

  5. Is “important” code separated from “necessary” code?  (“Important” for the business, “necessary” for the implementation)

  6. If I introduce a bug in the code, how many things will break?  Is that the number of things that should break? 

  7. Is there a lot of code churn?  (Churn hidden by refactors is still churn.) 

  8. What percentage of the code uses the right kinds of words? 

  9. How many teams & people are needed to implement a feature? 

    Across product, eng, sprint planning, number of bugs, etc. 

    How much code has to change? 

  10. How well is the code written?  I.e., how closely are the intended principles followed on a scale of 1-10? 

    Where do we want to be at, ideally? 

    What steps do we need to take to get that closer to where we want to be? 

  11. What is our definition of “done”?  Functionality implemented?  Has relevant unit tests? acceptance tests? important corner cases, error conditions, logging, i18n, a11y?  Is it actually in use, meeting KPIs, sought after, loved? 

    How close to done are we when we “finish a feature”? 

  12. If we wear our users’ shoes, how would we feel using what we build? 

    Does it fit our users naturally, is it design-for-design’s sake, fitting users to solutions, or something else? 

    Would it be an example of bad design or would it be award-winning? 

  13. ← (…list still in progress)