Personal/Team Software Process

Code Quality

  • There are no “rules” in software engineering. There are just things that have historically been proven to work. Call them ‘patterns’.
  • Before any project and then continually do the following:
    • Decide what “success” means for the business and how you’ll measure it.
    • Decide what “done” means for the team and how you’ll measure it.
    • Remove/Change anything that needs to be “done” which doesn’t contribute to “success”.
  • Ensure that any architecture can be explained to a brand new junior developer in such a way that they are productive within 1 to 4 hours of joining the team.
  • Write enough tests to both satisfy the “done” criteria and show cases the “success” condition.

Behavior Driven Development


Now that we have behaviors defined we’re almost ready to start architecting. Before that we want to identity which part of each behavior (functionality) has performance concerns at scales of 0 - N.


Satircal Examples: * FizzBuzz 1