Data is fundamental to the creation of software. It will routinely outlive the interpretations we derive from it and the applications we build on top of it. Therefore, we will always seek to lay the foundations of data management independently of a particular application or use-case, and above a common timeline.

Table-based structures, found in spreadsheets and traditional SQL databases, are helpful for displaying and analysing data, but they are not an appropriate format for storing data.

Tables are insufficient for representing data in its purest form, and this is particularly obvious when modelling sparse data or multi-valued attributes, or coping with the evolution of data over time.

Instead, we believe that data is best recorded as units of facts and relationships, without constraints.

More simply put, we believe graph-oriented systems point us towards the correct approach for data management, and organisations such as Facebook and Google have proved how powerful the widespread use of graph-structured data can be.

The software patterns and practices that underlie your application architecture are certainly important, but less fundamentally relevant than making the correct choices with regards to the structure of your data in time. Assuming those other foundations are in place, we believe that the best approach to code is to keep it short, readable and expressive.

In reality this means we prefer:

• Writing modular & generic libraries of functions that operate over many types of data structures
  
• Minimising the use of state wherever possible
  
• Maintaining declarative structures that avoid the need for reasoning about imperative control flows

By pulling out the state and domain, the remaining code is simple. Developers can focus on writing code to implement business logic, pure functional calculations and derivations, with resulting actions that automate the execution of business processes.

As software complexity is tamed, productivity soars.