Mobile Application Maintenance On the Light of Lehman Laws for Software Maintenance

Today most of the software are moving toward mobile, as mobility has successfully seduced most of the businesses to move toward it. Once a company start developing a mobile application it look an easy task as everything start simple but as soon as it started to get launched updates are required frequently in order to satisfy the user needed.

In this article, we will discuss the validity of Lehamn 8 laws published at 1974 on mobile applications. Lehman qualified the use of such laws by recognizing three classifications of programming:

  • A S-program is composed by a correct determination of what that program can do
  • A P-program is composed to execute certain systems that totally figure out what the program can do (the illustration said is a program to play chess)
  • An E-program is composed to play out some genuine movement; how it ought to carry on is firmly connected to the environment in which it runs, and such a program needs to adjust to fluctuating requirements and conditions in that environment

The laws are said to apply just to the last classification of frameworks.

Figure 1 Frequency of mobile updates (

L1: Continuous Changes:

Software should get continually changes otherwise it will become less satisfactory. Referring to a study on the European mobile based business application we will find that 25% of the applications are updated every month while 23% of the applications are updated every week. That prove the validity of this law for mobile application.

L2: Increasing Complexity

The complexity will increase unless work is done to reduce it. In most of the cases a mobile application is built with a minimal set of requirements due to the fast releases a lot of bad smell code is rewritten in order to meet the deadline. After some updates we could end up with a high complex software with maximum code debt, that why code maintenance should be done regularly in order to decrease the complexity of the code.

L3 : Self-regulation

Software Evolution and maintenance processes should be self-regulatory. In other words, organization Process should be more mature among the application development. Mobile application love DevOps and the core of DevOps is agile that show a big conflict with this statement. In DevOps we start with a setup that is rarely to get changed.

L4: Conservation of Organizational Stability

The average global activities is invariant over product lifetime. Partially valid for mobility as the emerging variation in the external environment require more work than normal evolution cases. Typical scenario happen when a new version of operating system is launched it will require more effort to make the app working on the new one. Or when the organization decide to adopt a new platform.

L5: Conservation of familiarity

Software update must be familiar to the original one. In mobile world this is enforced as the UI is initially; restrict by the platform in which the application is built for. In rare cases,we have some UI revamping but it must be accomplished with getting started tutorials for the users.

L6: Continuing Growth

Software functionalities should be increased not to be reduced in every release. In many cases, we have to reduce the functionalities provided by the application to maintain complexity and optimize resources utilization, it should be done by eliminating the functionality with less utilization. In some cases, we need to break down a big in application into smaller applications example Facebook Messenger.

L7: Decline Quality

Software quality will get declined if no updates are done for it. Due to continue environment operating system, devices… updates. Mobile applications will not survive if no updates are done. Mobile applications life-cycle apply Darwin life-cycle an application do not update to the environment it life on, it will die.

L8: Feedback System

Evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. Typically implemented in DevOps where we modify based on the utilization reports; in some cases, we predicate the user changes requests and we implement it before that.

Authored by: Ahmed Fouad