Design principles


A short list of "rules" set the standards and direction for the F3 project. These principles resolve any doubt about future developments and/or feature additions/removals.

True 3-tier architecture

Insist on the DB-Server-Client distinction.

Stick to Postgres, exploit it

Postgres has been the coolest design decision of TinyERP/OpenERP. We stick to that, forget about any "abstraction layer" that would reduce the set of Postgres features available.

Postgres (or any decent SQL database) is all about managing your data and implementing business logic on that data. Very close to what we expect from the ERP. Meaning that the DB can play an intelligent role in the ERP system. In particular, Postgres offers many high-end features (views, triggers, functions, notifications) that could take on the workings of the ERP. The IPC + multi-processing layer of Postgres is also more mature than any corresponding attempt in Python. That is, Postgres scales up much better than any Python system known so far. We'd better put the high load in PG, leave Python with lighter tasks.

Use Python, more of it

Python is another cool choice. Try to write the ERP on Python, avoiding mix of any other (imperative) programming language. Supporting libraries and declarative languages are fine, other languages are not.

Example: using YAML, XML, Jinja2 are fine, because they do what Python has not been designed for. But Java isn't, neither is Ruby, Lua, Scala, etc. Because Python can cover these languages enough, while keeping a project in more PL's is more expensive than any performance gain.

An exception would be C/C++ "accelerator" libraries, under the strict rule that they are drop-in replacements for Pythonic modules. If we can gain more than 2x the speed of Python with some C code, let's exploit that.

OTOH, don't go for Pythonic excellence

The ERP is not a programming contest, nor a showcase of code abilities. We prefer to stick to older API names and style (provided it's not broken), rather than go for Pythonic purity and strict PEPxx compliance.

There may be many different ways to write some code. If ours is not broken, we won't change it. Integrators and version maintainers will praise us for that.

ERP means business software. Stability is first

We may end up with little uglier UI, little harder constructs for the novice user to understand. But we do business here. Stability of the code (reducing the bugs, that is) is the priority. That, along with data_integrity (part of "stability", in a wider sense).

So, we prefer to have clean (in the functional sense) code, well-defined error paths and messages, rather than deliver a new feature faster.

Uptime is proof of good code

Server uptime is a great sign of good code and design. If the server does not crash, nor needs to be restarted, it means we are stable enough, or even extensible enough to do all things on a live system.

We rate our code on that.

Performance matters

Performance is the ratio of how much you get back from a given set of resources. We remain in the old school and try to maximize it, despite the "unlimited resources in the cloud" trend nowadays.

Everything has to run faster, and faster. The reason is not that we want to ignore the current offerings in CPUs etc. It is our engineering sense that resources can grow linearly (eg CPU speed, multiple cores), while our system complexity will grow exponentially (more data, by more code, by more checks, by more rules etc.) . Eventually, having optimized the very little bits will pay off.

We are not alone

Centralized development has gone of age. We are in the era of distributed projects and thought. Our design must be flexible and able to be hacked by different (often argueing) parts.

Framework for Gurus, applications for dummies

The balance of framework/apps (= modules) complexity is that of senior developers to junior ones. We chose to put all the magic in the server (aka framework) in order to let the applications be more fool-proof and easy to write/maintain.

So, seeing hacks in the applications means we had been doing something wrong. Trying to override incomplete server functionality should have alert us.

SQL is good, but people hate it

This design principle is influenced purely by experience on the site. We learned that people consider SQL bad, ugly, impossible to learn.

So, we hide it as much as possible from the application developer. The framework shall offer such a layer, that SQL won't need to be touched at all.

However, we must ensure that the framework's SQL code is optimal enough that the developer won't ever challenge it.

ERP is not a web-app, it's a platform

If we wanted to write web-pages we would be web-developers. But an ERP is much more than that. It's a central part of our /block design/ where several systems integrate. Just one of them is the web UI.

It's important that the ERP runs regardless of the web-part. It shall offer clean and full API's to hook any external technology on it, bridge it with any other (legacy, perhaps) system.

Developers are precious

Developers is what keeps a software project alive. We praise them, keep them happy. Especially in the open-source world, the motivation for them can only be from the code itself. Thus, the code must be readable, easy to debug, easy to hack.

Follow us