In this article I will be discussing techniques and an ideal mindset for developing successful web applications, which can be easily adapted to meet continuously changing business requirements.
A key problem when developing any business or marketing tool is that there is always a risk that certain features may not fulfil requirements as expected. These features may be expensive to implement for little gain.
Therefore it is much safer to initially develop a simple prototype or a minimum viable product. This would then be subject to real-world testing. The immediate benefit of this approach is that a simple version would be less expensive to develop and the development goals would be more achievable.
As soon as the initial version of a web application goes live, insights can be acquired which will allow a designer to determine the best course of action for the development of the next version. This may involve adding / removing / enhancing features and fixing problems.
In order for a web application to progress to the second version, it must be adaptable. Adaptability throughout an application’s life cycle is a key factor to its success.
Modular development is a useful production technique to ensure that this is the case. This technique involves breaking down an application’s file structure into separate folders. Each folder can be referred to as a module and should be responsible for providing or adapting a feature. The whole application can then be described as a modular application. Modularity offers the potential for efficient adaptation based on real world feedback.
Different frameworks use different names for modules, they are often referred to as either plugins, packages or modules. Some frameworks also use multiple terms to describe different types of modules.
A common alternative to modular development is where all functionality is organised in folders which are specific to a particular type of functionality. For example there may be a folder containing everything required for defining all URLs that can be accessed as part of a website. The advantage with this technique is that it provides a high level overview of what the application does.
However the disadvantage is that functionality is not organised in a way which relates directly to the features, user experience or overall purpose of the application. This means that adaptation in response to real world feedback requires a much deeper working knowledge of the whole application. Even with this knowledge it is likely that mistakes will still be made. Overall this means the application is less adaptable.
During real world testing of a modular application, insights may suggest that a feature should be adapted. If this is the case, then development work is only required on the single module responsible for implementing the feature. As modules are much smaller than the whole application, the change itself will be simpler, easier to understand, document and test in isolation of other non-dependent features.
If insights suggest that a feature should be removed, a developer would only need to delete the module that is responsible for providing that feature and any modules responsible for adapting the feature.
If insights suggest that an additional feature should be added to the application then an additional module can be developed to implement the feature. The advantage here is that any development work will not affect the user experience or introduce any backwards incompatibilities to the public API of the application infrastructure or other modules.
Modular development requires an understanding of modular dependency structure. This is where modules are dependent on other modules and the framework / infrastructure. Simple features can be described as a single dependency chain of modules. An example of this is as follows:
A WordPress site has a newsletter signup form on the homepage which submits user details to a third party mailing system. Please note that modules are referred to as plugins in the context of WordPress. This feature could be implemented by means of a plugin called “Webforms Plugin” that allows an administrator to create and publish webforms. There could also be a plugin called “Webform Mailing System Plugin” which is responsible for forwarding webform submissions to a third party mailing system.
The “Webform Mailing System Plugin” depends on the “Webforms Plugin” which in turn depends on “WordPress”. The dependency chain for this particular implementation can be described as follows:
WordPress < Webforms Plugin < Webform Mailing System Plugin
In this example, if the “Webform Mailing System Plugin“ is deleted then the rendering and submission process of the newsletter signup form will remain functional. It will simply not submit to the third party mailing system. This means that the particular third party could be completely replaced, without affecting the front end component or submission process.
After the initial feature goes live, it may be determined that the third party mailing system is receiving too many spam submissions. If this is the case then another module called “Webform Spam Protection Plugin” could be developed. This would be dependant on the “Webforms Plugin” but not dependant on the “Webform Mailing System Plugin”. Meaning that the feature can no longer be described as a single dependency chain, it must now be described as a dependency tree.
Complex applications with multiple features can be described using dependency tree diagrams which have multiple dependency chains, potentially interconnected and routed to the framework / core system. The following is an example of this, arrows represent dependency and dotted lines represent support between modules:
When planning the development of any modular application, creating a dependency tree diagram that can be adapted for new versions is extremely useful. Generally if a dependency tree diagram looks messy and highly interconnected, the less adaptable the application will be. Therefore by having a strong working knowledge of an application’s dependency tree, a developer can make decisions which will actively reduce unnecessary dependency and make the application more adaptable.
The main thing to avoid when developing a modular application is circular dependency, this is where two modules are dependent on each other. Therefore meaning that neither module can exist without the other. In this situation, both modules can essentially be considered to be the same module, the result of this is increased complexity.
Modules with higher levels of complexity are always harder to adapt. The ultimate goal of modular development is to break down an application into simple manageable chunks which can be adapted, fixed or removed.
Proud to partner with
