Developers, too, have the right to (h)appiness

Developers are often wandering and haggard human beings. Some think this is because software development is so exciting that everything else is poorly considered. Most probably, the reason is to be found in these complex problems that never go away from their minds. Nobody understands them. Their family? Their managers? Their clients? Their friends? No. Nobody. Nobody is able to imagine how huge and complex their tasks are. Consequently, what they do is underestimated. Worst: they can't communicate. Don't believe this is due to some intrinseque geek attitude. Their geekness results from the global incapacity to apprehend the very nature of their abilities. So they are forced to work harder while experiencing the true impossibility to share their permanent software experience. Of course, it may lead to social disasters.

By publishing this high-level, easy-to-use Python-based software construction kit,
our crazy hope is to empower developers in such a way that they can leave more often
their software prison and spend more time to discover real life.

But (h)appiness has a price. Appy developers themselves accepted to pay. They have dealed their social life for one of the highest forms of social denial (their working conditions can't be revealed), hoping their sacrifice will free the users of their work. If, one day, you meet one of them, please be gentle and patient. But they will probably not discuss with you.

The null-IT principle

Appy was built with this idea in mind:

Information Technology (IT) should be as transparent and invisible as possible.

While this may seem obvious, this principle is largely ridiculed by a great number of widespread technologies.

Other (counter-)principles

The following other principles underlie Appy.

A code-centric but conceptual approach

Appy works at a high level of abstraction. With it, you are not going to write a function that returns dynamic HTML when some URL is hit. You are going to define classes and relationships, and methods will be like hooks that will react when some events occur (an object is created, edited, deleted, etc). You don't have to write a single line of HTML, CSS or Javascript to write basic Appy apps. Only pure Python. This is what I call conceptual. But unlike most conceptual approaches, you will not draw any diagram or anything that is not Python code. Pure Python, pure simplicity, no repetition, no transformation: optimal efficiency, optimal maintainability. Other conceptual approaches like the idea of starting from some abstract vision like a (graphical) model (boxes, arrows...); from it, tools generate code skeletons that need to be completed in a subsequent "development" phase. Such "transformational" approaches may even count more than two phases and manipulate different models at different abstraction levels before producing code (this is what I have learned at the university). Such approaches spread the information in several places, because every model or representation has limited expressivity. In my opinion, it produces redundancy and eventually leads to maintenance problems. It violates the DRY principle, which is closely related to the Null-IT principle (see above). On the contrary, Appy knows only about code. The "model" you write is a Python package. Being written in a high-level programming language, it does not constrain your expressivity in any way. More important: this code is the running code, and thus the only place where you describe your software.

Violating the model-view-controller pattern (and a lot of other patterns, too)

Some design patterns are elegant low-level constructs used to overcome the limitations of programming languages or frameworks. Using some of them implies adding classes just for making the plumbery work; it augments code complexity and, again, spreads information at several places. Separating code describing data from code presenting it produces the same problem. Appy takes the approach of grouping everything at the same place. For example, information that dictates how a given field will be displayed in the user interface, manipulated in "business logic" and stored in the database will be grouped together as part of a unique field definition.

All-in-one objects

As a consequence, Appy objects (which are plain old Python objects: you do not even have to inherit from a base class) are self-sufficient. If you want to understand some (group of) functionality within a well-designed Appy app, you will not loose yourself walking through an intricate web of Python classes and XML definition files.

Building complex and shared web applications

While some out-of-the-box tools are mainly targeted at building websites of specific categories (informative sites, blogs...), they provide poor support for those who want to build complex and shared web applications.

By "complex", we mean real "business applications" (or "information systems", like accounting systems, HR systems or online booking systems) whose interfaces are web interfaces; a classical CMS-based website being a particular case whose main purpose is to provide information, with some limited degree of interaction with the user. Web business applications are characterized by (1) a rich conceptual model featuring a complex web of inter-related classes and (2) the need for complex searching and reporting facilities, be it through-the-web or within generated documents.

Currently, free software is widespread within the "IT infrastructure" (operating systems, networking components, web servers, application servers...) and contaminates more and more general-purpose software applications, like word processors, spreadsheets or multimedia players. For the most of it, the free movement currently reaches domains where requirements are either perfectly known by the developers themselves, deduced from observing proprietary software or part of some general cultural background. In order to raise freedom at the higher levels of business and innovation, we need new mechanisms allowing to tackle (business-)specific requirements, while maintaining the possibility to spread and share software from one organization to the other. Appy was built to cope with this new scale of challenges and proposes a set of built-in constructs for creating generic business kernels implementing common requirements and allowing to tailor it to the specific needs of a given organization.