Skip to content

Latest commit

 

History

History
39 lines (34 loc) · 2.4 KB

shipping.md

File metadata and controls

39 lines (34 loc) · 2.4 KB

Early Shipping Values

These value statements make sense in the context of a project that is early in its life when it is undergoing rapid development and prototyping.

  • We need to ship small and frequently. We must help engineers get comfortable delivering small and imperfect solutions. For those that are unable to do this right now, those of us that can, will help cut a path to this future and demonstrate how this can be achieved, because we have lived it.
  • We are never done shipping software. We’re interested in making software real, that is, getting it into production where our users and systems can interact. Before then, software is only an expression of an idea. Validation is fuel for new ideas.
  • When software is shipped, we are not done. We must learn to identify outcomes that are useful feedback as inputs for the next iteration. For example, if a small feature takes an hour to deploy, do we understand the conditions of that experience well enough to make improvements to it?
  • Let's define shipping as “getting code into the world so that others can use it.” This is an early and simple definition that is subject to change as our work expands. Right now, it means that we optimize our work to ship code, above other concerns. In practice, this means that concerns like test coverage and automated deployments get less attention in the short term.
  • It may feel weird or uncomfortable that we have many teams working independently, when cases exist where be believe dependencies exist. This feeling is valid and it means we’re doing a good job of working in parallel. As more of these teams begin to identify common blockers, positive friction builds, creating a strong signal that it is time for us to collectively assess our progress and create some shared patterns.

Notably absent from the above is a deeper treatment of topics like testing code or building operationally sound systems. These are important topics, to be sure. We do not believe that those topics need our immediate attention. As we validate our ideas and solutions and determine which things satisfy our needs, our codebases will evolve and we’ll spend the effort necessary to run mature them.

Also absent from the above is any discussion about performance. It is another important topic that doesn't need our immediate attention. A slow, but launched, product beats a blazing fast one that no one knows about.