Modularity in modern software development

Written by Cas Nouwens by order of Avans University of Applied Sciences, ‘s Hertogenbosch

Projectmembers: Dylan Schaafstra, Maarten van Alebeek, Koen Fransen, Nina Barkat, Rick Septer, Yorick de Jong

Published in: 2019

Cover photo by Andre A. Xavier on Unsplash

Abstract

Modularity is an old concept, being applied by Nasa as early as 1970 in the AMTRAN project. This article claims that modularity is still a relevant and essential part of software architecture design and development. Research done at Harvard in late 2007 shows that a lack of modularity in software design produces components that are harder to remove, maintain and augment. A book published in 2006 by Baldwin covers modularity as an essential component of software development, stating that modularity makes complexity manageable, enables parallel work and accommodates for future uncertainty. These points are reflected onto personal experiences and it is concluded that modularity is an old concept, but it still is a relevant and essential part of developing proper software that can withstand the test of time.

Background

Modularity has been a cornerstone of developing proper software as early as May of 1970, when Nasa published their System design and software description of AMTRAN, which explained that modularity was applied to manage the logical core loads (Dyer, 1970).

It is also discussed as a standard for software development in the book Software Engineering written by Dennis, J. B. (Dennis, 1975). Software companies do not create systems anymore, instead they create modules that are distinct parts of a larger system. They are designed independently of one another, yet with a means of cooperation kept in mind. Modularity allows tasks to be divided among groups, which can work independently and do not have to be part of the same team or even company. Compatibility is ensured by design rules or patterns that govern the architecture, interfaces and standardized tests.

Project

The project that is being implemented is a white-label chatbot app, a mobile app that will be used to demo a chatbot to potential customers of the client where the app will already be stylized to fit with the theme of the client. This app is developed with modularity and expandability in place, it is primarily applied to the multiple types of messages that the bot can send to the user. Writing modular code and using design patterns are essential.

Related Research Work

In December of 2007, MacCormack published the article “The Impact of Component Modularity on Design Evolution: Evidence from the Software Industry”, which looks for evidence of modularity in software impacting software evolution over the course of its lifespan. It concluded that tightly-coupled components are “harder to kill”, “harder to maintain” and “harder to augment” (MacCormack, December 2007).

The chapter “Modularity in Design of Complex Engineering Systems.” In the book: “Complex Engineered Systems. Understanding Complex Systems” published in 2006, explains the three main purposes that modularity within software serves, namely to make complexity manageable, to enable parallel work and to accommodate future uncertainty (Baldwin, 2006).

The purposes of modular design

Baldwin states that modularity has three purposes, keeping complexity manageable, enable parallel work and to accommodate future uncertainty (Baldwin, 2006), these will be expanded upon in the following paragraphs.

Baldwin states that modularity makes the complexity manageable by providing an effective division of cognitive labour, which makes it easier to grasp the purpose and task of separate modules (Baldwin, 2006). I experienced this personally in a school project, this project was to create a digital version of the boardgame Settlers of Catan. During this project modularity was not applied properly which resulted in overlapping responsibilities, heavy dependencies and a veritable maze of haphazardly implemented functionalities. After refactoring the code, separating functionality into individual classes and applying an inheritance pattern the complexity was reduced remarkably and the code became easier to oversee.

Baldwin also claims that modularity enables parallel work, claiming that work in modules can be done simultaneously, which reduces the time required to complete a job (Baldwin, 2006). Which I can attest to, it is strenuous to work in the same file with multiple people, separating the work into modules allows a team to work on different layers of the same requirement.

Ultimately, Baldwin suggests that applying modularity in the design of a complex system allows modules to be changed and improved over time without impacting the functionality of the system (Baldwin, 2006). I concur with this, by applying the right software patterns to the architecture classes can be added, removed and modified with much greater ease due to low-binding between the classes.

Impact of modularity

In December of 2007, Alan MacCormack, John Rusnak, and Carliss Baldwin published an article on the impact of modularity on design evolution, supporting their point of view with evidence from the software industry (MacCormack, December 2007). They used the evidence from the industry to support the following three statements:

Firstly, they show that tightly-coupled components are more difficult to remove from the product, due to their many connections to other classes and vice versa. It would prove arduous to remove a component and all references to it (MacCormack, December 2007). From my experience with inadequately designed software, an intern-developed project with too much code in a select few files and the task to refactor the code that is present into something proper, I can attest to tightly-coupled components being difficult to remove.

Secondly, it states that the tightly-coupled components are difficult to maintain; they might have to be changed or updated due to changes or additions in seemingly unrelated parts of the software (MacCormack, December 2007). With this I have had a first-hand experience, which occurred during another internship where changes needed to be made to legacy software, which resulted in a chain of changes that were spread throughout the codebase.

Finally, it argues that tightly-coupled components are harder to augment, which means that new components added to the software are significantly more modular than the legacy design (MacCormack, December 2007). This sounds like a positive, but it also results in the older components sticking out as poorly designed even more and it would be difficult to refactor them due to the two previously mentioned points.

Conclusions

Modularity is an old concept, but it is still relevant to this day

Nasa applied modularity to their software in the 1970’s and the concept has existed before that, this concept has withstood the test of time and has scarcely changed, the core concepts remain the same and the rewards of its implementation are undeniable.

Modularity is an essential part of software design

A modular design provides more overview and reduces complexity, it can be worked on by multiple developers, which reduces the runtime of the project, it can be adapted to unforeseen requirements and can be efficiently updated. All these properties allow for efficient development and preserve resources.

References

Baldwin, C. Y. (2006). Modularity in the design of complex engineering systems. In C. Y. Baldwin, Complex engineered systems (pp. 175-205). Berlin, Heidelberg: Springer.

Dennis, J. B. (1975). Modularity. In J. B. Dennis, Software Engineering (pp. 128-182). Berlin, Heidelberg: Springer.

Dyer, M. E. (1970). Amtran system design and software description. Huntsville, Alabamba: Teledyne Brown Engineering.

MacCormack, A. R. (December 2007). The impact of component modularity on design evolution: Evidence from the software industry. Cambridge, Boston: Harvard Business School Technology & Operations Mgt. Unit Research Paper, (08-038).