The Case for Modular Software

Truths:

• No application fits 100% of an organization’s needs 100% of the time.
  

• No user is exactly like another – no user’s software requirements are exactly like another's.
  

• Users requirements are not constant – vary with task, situation.

This leads to application explosion – organizations need many applications with overlapping functionality to cover their entire functional requirement ‘space’ or feature set.

Many problems are similar but not identical – i.e. there is hope for reusable solutions if we can correctly "separate what changes from what doesn’t change". (Bruce Eckel - Thinking in Java)

The 80/20 Rule of Software:

The 80/20 rule is based on the above observation that no application solves 100% of an organization’s functional needs - a very good one might solve 80% leaving the remaining 20% for customization/ extension.

 

The 80/20 rule states that the first 80% is easy, the remaining 20% is either hard or impossible - leading to a more precise 80/10/10 formulation – where 80% is easy, 10% is difficult and 10% is impossible.

 

Depending on software quality, these numbers will vary but if the ‘impossible’ segment is a mission-critical feature for the organization, then the software cannot satisfy the organization’s needs, period.

 

The problem is that the breakdown of what is easy, hard or not possible is often not apparent when the software is purchased, and it may be possible to get a feature “kind of” working, in a prototype. However, when it comes time to deploy it to production, if a function is not working reliably and/or efficiently – that may be the same as not working at all!

Solution: Develop modular software - pluggable / reusable.

The goal of modular software is to never have this three way split and to modify the meaning of the 80/20 rule to 80% is easy and the remaining 20% is both doable and relatively easy to do.

• The hardware industry has known this truth for a long time – If a PC manufacturer had to develop a new PC from raw components – transistors, resistors, capacitors etc. it would be impossible to deliver a new machine at a competitive cost. Or if a PC manufacturer had to rely on a particular chip vendor, the cost and/or time to market might be a product killer if that vendors production schedules were not compatible with the PC maker’s needs.

• The modularity provided by the integrated circuit and the evolution of ever more powerful / interchangable chips has been the driving force behind Moore’s law – which states that computers will continue to get more powerful and less expensive at the same time.

• Software development has followed this trend much more slowly and most software systems being written today do not follow best practices when it comes to building modular systems even though software developers have had the tools to do this (Object Oriented development and Design Patterns) for some time.

• Object Oriented Methods – promised code re-use but as experience has proven by itself the Object Oriented method cannot deliver this. Specifically: IF the interconnections of an object model must be fixed at compile time, especially the class names of all of the objects – then truly modular software is not possible.

• Several key innovations of Java enable modular software – notably the ClassLoader and its ability to provide dynamic or run-time object creation and the abstract interface class which provides for pure interface definitions – totally polymorphic systems.

• Design Patterns - and in particular the Factory Pattern and the Delegate or Composite Pattern when combined with the use of pure interfaces enable truly modular software to be created.

• But even with the innovations of Java and the advances in the art of Design Patterns, it takes a while for programmers to change their ways because unfortunately, writing modular software systems requires some discipline.

Benefits of modular software systems:

• Cheaper – modular software means that code IS reused. Easier to maintain because there are fewer interdependencies between objects. Systems can be extended by combining modules rather than by “clone and tweak” – which leads to an explosion of code that is very similar but not identical – making bugs very hard to isolate and fix.

• More robust – a fully modular system enables object encapsulation to be achieved throughout. Modules are tested under different conditions, ensuring greater stability then code that is written and tested once.

• Consistent - modular software designs enable systems to be developed in a more consistent fashion. This provides benefits to organizations that create and maintain large systems because system design is consistent making it easier for developers to understand new systems built with the same framework.

• Future proof:

  • Extensibility is a core feature of modular software. If interfaces are based on unchanging principles of information and language structure - such as the grammatical "triple" Subject - Predicate - Object. The rest is implementation which is changeable.

   

  • Pluggability provides the ability to replace entire systems (especially costly ones) or software packages without disrupting other parts of the application.

Best Practices for Modular Software Development:

• Use Open Standards wherever possible. ( HTTP, FTP, SOAP, LDAP, SQL, RSS, RDF, etc).
  

• Use Abstract Interfaces so that there is no coupling between implementation and interface. Each interface should do one thing.
  

• Use Design Patterns – combined with good interfaces enables serious object reuse.
  

• Use containment / composite patterns – complex functions are built from simpler – more easily verified components.
  

• Use XML – driven Factory Patterns that enable configuration and configurable composition.