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.