Embracing Change for Dynamic Software Development

January 25, 2017

Many factors should be considered when planning a new software project; users, business requirements, technology, and countless others. One important factor should be planning for change. Whether you are working in the development process, testing, or five years after the software has launched, one thing is certain: change is constant.

Thankfully, there is a way to prepare for change without considering all possible futures: Dynamic, Change Aware Software Design (DCAD).

The concept is actually simple. While the typical software project is designed around features derived from requirements, in the DCAD approach, functionality is instead grouped into ‘areas’ that serve as extensible systems. The software is then designed around these systems (from which the features emerge).  Going in-depth with this concept could fill an entire technical reference, but for the sake of giving some meaningful information in this article, it will be condensed to its core elements.

What’s the point?

What are the benefits?

• DCAD can be more work up front (either a little or a lot), but will ultimately save time and money in the longer term , as well as increase the life of the software.
• The real beauty of working in a system-based application as a developer is working in verticals.  The changes made in one area of the application should not impact the rest of the application, when the pattern is applied properly. This reduces the need for most unit tests and extensive regression testing, resulting in faster deployment of new builds at a higher degree of confidence.
• Multiple developers are also able to work on the same application with minimal interference.
• Depending on the scope of the system, the end user may be able to employ changes immediately themselves which would otherwise require a developer or a new build.
• Additionally, new functionality can be ‘bolted on’ to existing systems with speedy turnaround from the development team, making it much easier to estimate time and effort for a change request.

DCAD can be applied to an existing software application, though typically in a limited scope.  The method works best when starting from scratch, mostly because it is heavily reliant on a dynamic data structure.  The more control the developer has in this area, the more effective the pattern will be.  Some relatively recent technology (non-relational data stores) can help alleviate the need for total control over the application database(s).

Let’s break down a few of the core concepts of DCAD in some detail .

Thinking Differently

The most important step in the DCAD process is the first one; reviewing the requirements in order to derive sets of functionality that can be grouped together as a system.  The average software project will have anywhere from 3-6 systems.  If there are any less, or any more, the requirements likely need to be reevaluated.

Here is a very simple example of how to define systems:

Application Requirements:

• Users need to be able to send messages to other users
• Users need to be able to let their supervisors know when they need office supplies
• Users need to be able to alert other users when a task has been completed
• Users need to be able to attach files to alerts and messages
• Supervisors need to be able to sign off on requests for supplies
• Supervisors need to be able to review other users messages

Some functionality can be identified from this list of requirements – notifications, messaging, alerts, file management, and role based operations.  Messaging, notifications, and alerts can likely be grouped into a single system, file management another, and role based operations can be tied into a security system.  We’ve broken six requirements down into three systems.  Consider that there could be dozens of other similar requirements which could fit into these defined systems: events, file management, and security.

Why have these been identified as areas of change?  For the purposes of this example – the business could request any number of other event types or rules, new file management tasks, or new security measures – these are all likely scenarios.

One of these is a great candidate for a user configurable system – events.  After determining what constitutes an event using a data driven interface, an end user could create new events using predefined rules without any developer support.  Adding a new rule? This would require a developer to ‘bolt on’ a new rule following the existing pattern for rules in the event system with very rapid turnaround and zero impact to the other areas of the application.

Application Driven Data Structure

The idea here is to let the application determine the data structure as it’s developed, which is handled through a migration process.

Adding a new domain model?  Create a migration to support it.

Adding or removing a field from an existing domain model? Migration.

Supplying some default data for base application functionality? Migration.

Every time the application needs a data change, write and deploy a new migration.  This accomplishes a couple of things. It allows the developer to quickly switch between schema revisions while keeping a historical record of how the database has evolved, but more importantly ‘frees’ the application from the constraints of data.  Often times, applications cannot be changed because they are chained to an existing rigid data structure. Designing the database first will only limit the possibilities of the software.

Data Driven User Interface

In order for an application to be truly dynamic, the user interface should be constructed almost entirely by utilizing templates and data. The templates could even be defined through the data.  The main benefit of this approach is being able to quickly update the user interface (adding new fields, disabling existing functionality, changing display text, adding new interactions) without having to rebuild and deploy the application.  A good metric for determining which areas of the user interface should be built this way – is to evaluate how closely the screen(s) may be coupled to one of the more volatile areas of the software.  A completely rigid interface tied to a dynamic system is a recipe for failure – it is crucial to create a user interface as change aware as the functionality it’s built for.

Change awareness isn’t a new concept, but it’s a concept that has evolved as often as the software inspired by it.  The pattern can be applied across the entire project scale, from the smallest web or mobile application – to a massive enterprise level effort.  By utilizing a dynamic, change aware design pattern, the stress, anxiety, fear, and apprehension associated with rapidly changing requirements becomes a much more manageable, and pleasant software development experience.