“Simply McCoy” as one of our brand values puts us at odds with our daily activities. As mankind’s technological adoption increases at an ever faster pace, complexity in the modern world is unavoidable. It is however the approach to managing complexity which enables simplification. Albert Einstein once said “Everything should be made as simple as possible, but not simpler.”
Having spent many years in the SAP industry we often encounter custom applications that are difficult to maintain. It is also the case that the impact of changes to applications is difficult to judge from the perspective of risk, time and cost. We are of course not alone in pointing out and addressing these challenges.
In this blog I present an approach towards improving an aspect of software architecture. Combining ideas from the past with contemporary methods can also lead to innovation. The concept of the Finite State Machine has, to my knowledge, never been widely implemented in business application software. FSM is better known in the levels of abstraction closer to hardware.
By combining commonly used techniques such as Object Orientation with FSM at the detail module implementation, I have experienced that software complexity is better managed. So what exactly is a Finite State Machine? FSM is a technique by which an algorithm is represented in terms of defined states and transitions between these states. As the name suggests states are finite in number and transition between states are deterministic.
Essentially it is a design pattern in which program control flow transitions from an initial state through a number of defined states and ultimately to completion.
Basically any method (module) of significance will be designed and coded according to the FSM principle. FSM is simply a different way of designing an algorithm and arranging software code so that it improves flexibility and maintainability.
This FSM design (and algorithm) can be clearly represented in a flow chart, for example:
Resulting code within a module contains much clearer separation of concerns therefore changes in the future can be introduced with less effort and risk. For example if the algorithm requires changes in the future you can simply introduce a new STATE in the FSM with little change to existing logic.
By better modeling the algorithm into its solution steps the FSM and related state transition diagram provides good documentation and a point of reference across business, functional and technical domains.
Debugging an algorith designed in FSM structure allows targetting the debug effort to any particular step of the algorithm.
Resulting code contains less nesting when compared to non-FSM implementations. The resulting cleaner code is easier to read and therefore easier to maintain.
FSM can be implemented in a simple approach using a loop, switch and a state variable.
The basic structure of a module written with FSM design techniques is as follows:
DO loop (until state_exit)
set next state
As in many other cases one’s objective should never be to implement a concept to its fullest and purest form. Rather use concepts from various disciplines in a way that makes practical sense for the application at hand. We have implemented these concepts with success in our software development at our customers. Innovation not only comes from new concepts but also by finding new ways to combine and use existing concepts.
Large application software often tend to remain in use at customers for a long time therefore future maintenance costs must feature in the discussion. Applying techniques that can effectively manage the complexity in the code base will translate to benefits for the organization. Consider using FSM techniques to improve software development in your team.