How

Question Everything.

Top Down

We build tools that match the design language used to express the solution as opposed to finding a way to map that design language efficiently to a programming language. This means we build visual tooling and dedicated configuration GUI's with a limited set of concepts rather than finding a suitable textual syntax and adding it to a vast amount of unnecessary technical concepts.

We obviously recognize that programming still has its place to solve complex or custom issues which is why we always provide a way to go off the beaten track and do something entirely different. The vast majority of business problems however can be solved without having to resort to code.

Simple things should be easy, complex things should be possible.

Readability over Writability

The most important thing an application needs to be (apart from functional) is discoverable. A member that is new to the team should be able to quickly navigate the application and find his way. This means there is an emphasis on the end result being as readable as possible rather than focusing on minimal effort or automagical properties and behavior.

This also means we try to provide a single way to solve a particular problem rather than multiple slightly different alternatives where you have to read the fine print to understand exactly how they are different.

The application should be the documentation.

Layered Approach

When looking at a particular solution, you should be able to see the overall design first. You should be able to understand at a high level what is going on at first glance and upon choosing something, be able to dig deeper. What does this mean though?

Suppose you are calling 2 REST services. Which ones and why you are calling them is the most important thing. It conveys intent and the general outline of your solution. At a secondary level we might look at how the data flows from one service to the next which is still generally a design consideration. At a third level we might care about endpoints and security. Only at a distant fourth level do we care about how this is logged, audited, transacted,... This is obviously important for the resulting application, but it is not important when trying to understand the problem and its solution.

In a lot of systems, there is no distinction between these things, they are laid out sequentially at the same level which can make it hard to filter out the bits that are relevant to you. At that point you lose the business logic in all that technical noise.

Question Everything

When the platform was first getting started, we often ran into the same question "should we try and adapt what is already there or make something new?". In the beginning we often tried to adapt what was already there only to conclude that it could not be made to do what we needed it to do. In a few cases we could actually achieve our goals -at least partially- but only by digging deep into the private code which would be subject to arbitrary change based on a roadmap that did not take our interests to heart. One particular decision by Red Hat to rewrite JBoss from scratch cost us a lot of work.

By being forced to rebuild however, we also often started questioning the existing solutions. To give a concrete example of this, we originally built a message broker that closely resembled JMS. Why? Everyone uses JMS, it is the obvious solution. It was however a complex piece of software that ultimately did not meet our expectations of "easy to use". We went back to the drawing board, took a very close look at our requirements and built an alternative framework that is much lighter weight and extremely easy to use. This is not meant to disrespect JMS, it is meant to highlight the importance of truly understanding your requirements rather than taking of the shelf solutions that sort-of-kind-of do what you might need them to do.

As a design rule, when we want to create something new in the platform, we first mentally design our own solution to the problem before we look at existing solutions. If we conclude that the existing solutions closely match our own (or are vastly superior), we can opt to include them.

Focus on what you need, not what you have.

May 13, 2019
Alexander Verbruggen