Evenja®

In order to define what software is, let's look at different ways of viewing, or grouping software using the classical layers: software from the point of view of users and programmers. The goal is to find commonalities between them in order to understand what software is.

Experienced programmers know that all types of software have their own constraints: programming an accounting program has constraints that a drawing application has not, and games have yet another set of constraints. The constraints for a particular kind of software mold not only the internal structure of its code, but also dictate the importance of different aspects of the software and creates a hierarchy.

Wikipedia describe many types of software:

• Application
• System
  • Operating system
  • Device driver
  • Utilities
• Malicious or malware

This is the classical categorization of software types, from the point of view of the end-user.

• User
• Application
• Operating system
• Hardware
• Utilities
• Malware

Internet users might be surprised by the last two categories, utilities and malware, as they do not appear in Web services. The Procedure page explains their existence.

Each type of software has different requirements, shown in the table below:

Example : Media software like Movie, Music or Graphic editors, most of all need High Speed. Management software like Accounts management or ERP, need Data Security. Games need Fast user interfaces.

Software categorization can also be done from the point of view of programmers, by project type: programming an operating system have other constraints than creating an accounting system. The following table categorize software by project type and give a grade on three criterion for each:

No bug means minor bugs that will not interfere with the quality of the software output.

Given the above categorizations we made, we can see that each kind of software has its specific needs and constraints. Each analyst, by using a specific approach and point of view, with his own experiences and the way he envision the final product, will prioritize differently the creation of the program. The prioritizations shown in the tables above are not universal, everyone can have different ones given his own experience.

But then how can we answer the question:

• How can we create software without bugs and in simpler ways?

Now that we can see that all programmer, even the best ones, see the problem differently at some point during the development, we can understand that those differences, which do not appear in the code and won't be obvious to members of a development team, come with a high risk of bugs in the code.

To avoid potential bugs because of misunderstandings among the development team members, we need to find the smallest common between all application types, applications and programmers, so we could have a common ground on which users, programmers and applications can communicate, in a simpler way.

Some have tried to find the lowest common denominator between users, programmers and applications by defining new standards:

• Languages such as Java, Perl, Python, Scala: simpler, therefore more widely understandable.
• Workflows such as UML, AGILE: more organized, therefore simpler.
• Libraries such as Qt, .Net, Fireworks: several platform, therefore less complications.

People with a little experience know that even with the help of one or several of those standards, bug appear. In facts, if a project the more a project is big and takes time, the more programmers will be needed to maintain it and make it evolve.

So the next question is:

• How a small team can make big applications?

Since even the use of evolved languages, libraries and workflows cannot prevent bugs, it means that they are not able to provide a complete solution.

So what ?

The common point between all components, human on electronic, of a software is its reality, what it actually does, what the programmer wanted it to do. Another way to put it is: What does the program actually do that the programmer programmed it to do? The answer should be something common for all type of applications…

• Management
• Media
• Mail
• Games
• Device FW
• …

… and whatever the project type…

• Operating system
• Driver
• User Interface
• Accounting
• For Banks
• Management
• Game
• Compiler

Is there a way to break down the applications which will show the same base element whatever the application, as a few kinds of atoms common to all and every kinds of objects?

The base building blocs of all software defined in 1992 by Fabian J. Padilla is the following:

• Read, put a value in a variable
• Write, put the value of a variable where it is needed
• Split, copy the content of a variable to another one
• Merge, combine the content of two variables into a single one
• Modify, modify the content of a variable
• If value, condition about the value of the content of a variable
• If function, condition about the value of the content of a variable, that will define a different end-user functional behavior

Those base tasks are inspired by the old assembly languages such as Signetics 2650, Zilog 80, Intel 8080 and 8048, and others from less powerful processors of the 70's. At that time, each byte was important and every instruction precious. The programmer needed to know precisely what was needed.

We don't consider IRQ management or DMA tasks, as they are taken in charge of by hardware or the operating system, beyond the focus of Evenja.

This definition of the 7 tasks, can be used in any software of any type, in any languages, used in any condition, by all programmers. This is the principle of Evenja.

Next page of Evenja's theory, Procedure.