Development Team Principles

The key principles and values of our development team

Our Principles:

  • Create software that:
    • is commercially successful, 
    • massively scalable, 
    • flexible for a variety of use cases,
    • can be maintained and extended by a very small group,
    • works on a large number of platforms.
  • Have a work experience that attracts and retains the most capable professionals.

Our Values:

  • We prefer a small team of very experienced and capable people.
    • Decisions and communication are faster when more relevant concepts are familiar or understood.
    • Less coaching is necessary, and ramp-up times are shorter when learning a new area of the software.
    • Peer reviews are more insightful.
    • Analysis discussions are more elegant, requiring fewer voices to reach similar or better results.
    • Dunning-Kruger is less of a problem.
  • We use JavaScript and JSON for anything we reasonably can.  
    • This is not because we are opposed to polyglots or using the most appropriate language for the task. 
      • JavaScript is available on almost every platform we use.
      • It requires less training and ramp-up time for people to work in different parts of the application.
      • It is easier to share code and tooling between projects, modules, and people.
      • Instances of data are almost identical in every application tier and storage mechanism.  
      • Because of the above reasons, we need fewer people and create less waste.
  • We value pragmatism.
    • We avoid implementing anything that cannot increase profits or the future value of our organization.
      • Building an optimized, maintainable code-pipeline is very profitable long term.
    • If there is a better way to do something (where better balances effort, disruption, quality, performance, maintainability, and enjoyment) then we are probably going to adopt it.
      • We do not value shiny new things unless they offer overwhelming benefits to compensate for the pain and time-suck of beta.
      • Sometimes it will take effort to convince the group a change is worth its cost (in time, disruption, etc.), so bring persuasive fact-based arguments.  Be persistent, but only if you are right.
  • We value elegant code.
    • We use configuration extensively to allow fewer modules to perform tasks for a wider variety of consumers.
      • We create tools and applications to enable sophisticated and safe configuration by non-developers.
    • This almost always takes longer the first time a feature or component is built.
    • Experience and (more importantly) success have shown us it is far easier to maintain a smaller, but more flexible total codebase in this way.
  • We value quality and automation as tools to reduce churn and time to market.
    • Unit-test code coverage is very high across the board (and no, we don't get hung up on the actual statistics).
    • We put all code through CI and are moving toward CD.
    • Our UI test automation is a flexible and substantial body of code that increases with nearly every release.
    • Because our architecture is unique, we dogfood our own software platform to deploy itself in a repeatable, consistent fashion, with one touch. This means all MongoDB, Kubernetes, application configuration, and Web UI changes are deployed with the push of one confirmation button.
  • We value friction of ideas.
    • Pull requests rarely make it through without revisions.
    • Valid criticism is usually awarded praise and respect.
    • Disagreements, when they occur, are used to unearth facts, share experiences, and derive a better solution.
    • We value diversity of thought, meaning heterogeneous groups are often more capable of expanding and refining ideas. 
  • We value kindness (which is not the same thing as being nice).
    • On a small team, it is necessary to build each other up, to offer help, and to provide flexibility for varying personalities and life experiences.
  • We value people that get things done.
    • There's no room on a small team for slackers or people easily distracted from our goals.
    • Individuals have areas of expertise, but rarely only one.  Most competencies are shared by another person.
    • Managerial overhead is limited; team members receive direction and must execute with little oversight.
    • Requirements are usually high level. Further analysis and clarification is often necessary and is performed by whoever picks up a work item. 
  • We value continuous improvement.
    • Building features perfectly the first time is unlikely and trying to do so is sometimes inefficient.
    • Pull requests should incrementally improve code which is in the same context as the primary focus.