8. Technology

We use Technology to build great software that we can easily live with.

We identify the minimal viable amount of planning to sprint in the right direction

• We expect written documentation of feature sets from the product team (and indirectly from sales).

  • Features already present in our application

  • Features of key competitors

  • Features demanded in the market, classified by customer category. We assess these key attributes:

    • Is it a nice-to-haves or a deal-breaker?

    • What’s the resulting value for us?

    • What are dependencies to other features?

  • Feature ideas not yet demanded

• We build prototypes to test assumptions.

• When we’re confident, we build the MVP with the smallest possible feature set that adds value.

• If we decide to keep prototype code instead of building an MVP we make the additional technical debt visible.

• We structure our applications to support team, feature and customer growth.

  • By building 🌏 modular structures (e.g. 🌏 Microservices, preferably 🌏 reactive), we optimize for throwing away and replacing code without affecting the whole building. That way it’s okay to write hard-to-maintain code and keep the result easy to live with.

  • We use 🌏 the 12 Factors for building a SaaS app as much as possible

  • We use feature toggles to allow adjusting feature sets with minimal code changes.

  • Prototypes can ignore these best practices because they will be discarded or cleaned up early.

• We plan for interactions between what we build (components, products and third-parties).

  • We build meaningful APIs with versioning, security and intuitiveness in mind.

  • We use 🌏 Semantic Versioning.

• We use tools from DDD like event storming to form and document an understanding of our domain.

Maintainability over Speed over Beauty

To understand what good software is, we need quick customer feedback. The only thing more important than that is that we remain able to run and change what we build. Hacky solutions are okay as long as they’re isolated and easy to replace.

Complementary Products over Interconnectivity over Single Product

Our customers are diverse and don’t (yet) demand our products to be integrated. This will change in the future. In an evolving market, the best way of allowing future integration is to build proper products and not to try anticipating what integrations will make sense.

We move faster by writing tested software.

• We know that properly doing TDD allows us to deliver features faster and reduces follow-up cost from bugs.

• In keeping with BDD we don’t couple tests to implementation to allow refactoring and living documentation.

• While planning features, we decide on how to test them.

• We never skip tests for business logic.

We use standard ways of cutting down complexity.

• Separation of concerns

• Inversion of control

• Design patterns

• Purity and idempotence of functions and systems

• Immutability of data

• Reactivity (for distributed stateful systems)

We make our code and its history self-documenting.

• Our commits are gifts for future engineers. We make commits 🌏 atomic, 🌏 semantic and add ticket IDs to commit messages to make our git history meaningful and simplify patching and merging.
• Our documentation explains the Why, not the What (which should be understandable from the implementation).

• We document our infrastructure, flows, and connections between services in easy to read and maintainable diagrams.

We choose languages, tools and libraries based on …

• … their utility and whether they’re appropriate for the task at hand.

• … their quality.

• … the maturity of the ecosystem (community, tooling support, documentation).

• … how well the principles behind it align with what’s important to us.

• … their longevity.

• … support by major players.

• … experience in our team and the talent pool.

• … our ability to maintain them.