Posts Tags
confinus.com
Engineering Blog
About building Confinus: the ultimate food industry empowerment platform 🤘💪🏾
Our guiding engineering principles

At the start of a big project the temptation is to rush ahead and build without worrying too much about what you are actually building. After all, getting something out there so the business can start testing and learning is really so important.

It is just a prototype you muse… anything goes. The next thing you know, 2 years down the line, and that flakey and badly written prototype is the foundation of your main product. It is always too hard to just throw away things that work.

Thus at Confinus we set down a set of guidelines very early on during the process of the product development to ensure that the product was development in a sustainable way, trying to ensure that the one codebase would be usable for years to come.

While these have been iterated and have changed a bit over time, they have helped us immensely whenever we come to make decisions in engineering here at Confinus. Something to focus the mind!

The Confinus Engineering principles and guidelines:

  • Sensibly balance implementation effort and speed, the quality of the result and the business need for it. Don't aim too high or too low. Don't ignore one part over another. However lean to the side of delivering business value with quality over lowering effort or increasing speed.
  • Have a development process and a team empowered to decide on the above balance themselves
  • Maintainability and consistency are paramount. The codebase may have been built by 14 developer so far, but it should look and feel like a ‘whole’.

Generally:

  • Strive for a great code review process that encapsulates these principles.
  • Consistent iteration and always leave code kinda better than when you started touching it (don't obsess though!).
  • Favour verbosity and readability over terseness and complexity.
  • Core re-usable patterns should be designed, built and maintained to aid consistency
  • Core patterns should automatically provide best practices and do the right thing
  • Core patterns should be a pleasure to use and make the developers able to move faster
  • Sufficient documentation and easy on boarding for new developers.

In the codebase:

  • Developer should find the code base ‘familiar’ and not diverge too far from familiar Rails territory
  • Use well maintained gems with maturity and good history of maintenance, otherwise take inspiration for unmaintained ones then roll your own (into Core patterns).
  • Embrace convention over configuration and always provide sensible defaults
  • Use linters and static analysis
  • Provide an up to date and really useful set of Fixtures which represents a snapshot of the DB at any point in time with ‘real’ fake data. The data set must be easily maintained (the data is invaluable to rapidly set up demo and user testing envs, and for developers to build against without compromising user privacy).
  • Avoid heavy weight frameworks and steep learning curves
  • Provide backend devs with the tools to compose modular front end components without needed to go deep into the FE code. Empower full stack development and blur the lines between back and front end.

Testing:

  • Aim for great test coverage, but not 100%, be realistic and focus attention.
  • Unit tests should be fast and run consistently (focus on testing only the unit, uses mocks/stubs etc)
  • Integration tests should be as fast as possible, without compromising the usefulness of the test (dont just stub everything out!)
  • Feature tests should aim for maximum impact. Write few but make sure they test the most important features and flows of the platform.

Design system pattern library:

  • Create a strongly aligned pattern libraries between design and development
  • Create a well documented pattern library with live components to play with and explore