The Three Laws of Softwaristics

Posted by Pascal Polverini on Sep 14, 2015 12:32:48 PM

    

 

In 1942, Isaac Asimov introduced the sci-fi literature world to the Three Laws of Robotics:

  1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.

  2. A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.

  3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Thinking about software application development, debugging, maintenance, deployment and overall application evolution, I propose that the same law structure be applied to software:

The Three Laws of Softwaristics:

  1. Software may only use open standards or, if nonexistent, use interoperable formats.

  2. Software must use a multitier architecture, except where such architecture would conflict with the First Law.

  3. Software must centralize its logic, as long as such centralization does not conflict with the First or Second Law.

 Law 1 – Open Standards

Software may only use open standards or, if non-existent, use interoperable formats.

This law applies to software languages as well as data formats. If the technical specification for the language or the format is public, then it’s open.

Ruby and PHP are open-standard programming languages, XML and HTML are open-standard formats, and HTTP is an open-standard protocol. And while not truly open, Java* and RPG follow standards as well, rather than introducing cost and risk by reinventing the wheel. This also introduces risk for the sustainability of the software, as whoever uses it after you may not be able to maintain it. However, when standards are followed, you don’t have to think about it anymore, as the standard secures the sustainability of the software as technology evolves. The technological evolution will either change the standard and provide a means of conversion from the old version to a new one or offer new products that will integrate the existing standard.

A good example of this would be Open Office. To make it widely used by the community, the developers created a converter from Microsoft* Word. The new RPG IV standard is similar, with the command CVTRPGSRC to convert RPG III to RPG IV.

Law 2- Multi-tier

Software must use a multi-tier architecture except where such architecture would conflict with the First Law.

 Tiers could differ in naming, but the standard multitier model comprises three core tiers in three respective blocks: The data tier, which stores the data; the application tier, which processes the data; and the presentation tier, which presents the data and enables input.

For example, Excel spreadsheets include all three tiers in one single block, which is bad from an application perspective. This is why the .csv format was invented. It represents a data tier block separated from the presentation tier block. Text messaging uses two tiers in one block: presentation and data. More sophisticated software, like ERP or CRM, will have all three tiers in different blocks for databases, business processes and different presentation channels.

Having an app divided into multitier blocks allows each tier to be separately developed, tested, executed, reused or substituted.

A tier could be logical or physical. Physical tiers are entire blocks (e.g., a database file or a cascading style sheet), and it’s easy to substitute a physical tier with another one.

Law 3 - Central Logic

Software must centralize its logic, as long as such centralization does not conflict with the First or Second Law.

This law concerns logical rules, (aka business rules). You can have absolute or relative rules.

An absolute rule can contemplate the type of a data field, its validation or its correlation to another field. For instance, a field can be set to always display a date or a number, or to always be validated in a unique way. It can also be set to not exist if it’s not defined in a header file.

A relative rule can depend on the user login, contextual data or the environment. For example, if I must show a grid made of five columns on a GUI, I may show the entire grid on a browser desktop but only one column on a smartphone.

What matters in our open- standard and multitier premises is that absolute rules are defined at the data tier or, if not possible, at the application tier. Relative rules are defined at the application tier and, if not applicable, at the presentation tier.

This post is an excerpt from the full-length article The Three Laws of Softwaristics, published in IBM Systems Magazine. I invite you to read the article to learn about the three laws in more detail, and about why these fundamentals are meaningful.

Also, think about your personal experience in application development, debugging and maintenance. How do these three laws apply? I would love to hear your comments or feedback. Drop me a line: pascal.polverini@freschelegacy.com.

 

 

Topics: Mobile, GUI, Application Modernization, Software, Application debugging, XML, RPG, Ruby, PHP, HTML, Java, HTTP, Application development

Subscribe via E-mail


Follow looksoftware