Maintainable Software Overview

The purpose of this blog is to promote the creation of software and firmware which is designed to be maintained.

The focus is on ways and means of creating software which are as independent as possible of any development environment/eco system.  That is to say it will focus on aspects of software architecture, design and coding practices which will maximize maintainability.

All of the information presented here is based on forty plus years of personal experience as a software engineer and anecdotal material from co-workers.    The material presented is expected to be applied where practical and with at least a good understanding of why it does or does not apply to a specific situation.

My experience has been primarily with main-frame and workstation class computer systems.    Programs requiring a Graphical User Interface and Web based applications have not been considered primarily due to insufficient experience.  Non application software (device drivers, file systems and midlevel network code, language compilers etc.) is also not specifically considered primarily because often the need for speed or severe constraints on RAM and/or other resources override some of the recommendations.

I have defined maintainability as:  a measure of the effort required to change the functionality of application software.  A measure of ‘effort’ must include time, resources and expertise.

In general any software development manager is familiar with this definition of ‘effort’ as it applies to creating software.  The term ‘change the functionality’ applies to both enhancements as well as bug fixes.   It might also be said that maintainable code is designed to be leveraged.

Maintainability is related to several other “ilities” such as

•  Flexibility:  The ability to work with un-anticipated data/conditions without code changes.
• Portability:  The ability to operate in environments other than the one originally deployed in.
•  Reliability:  The ability to operate correctly in-spite of failures in the programs environment or inconsistencies in the supplied data.
•  Reusability:  The ability to use code in a different application without modification.  It could be said that this is the ultimate goal of maintainability.

    A program has been described as being composed of data and algorithms.  I also add control or control flow.  I use the term ‘algorithm’ to refer to any section of code which manipulates application data.  The term ‘control’ refers to code which determines which algorithms and/or the order in which algorithms are executed.  It can therefore be stated that ‘data + algorithms + control = program’.

Experience has shown that the areas of volatility from greatest to least are:

1.  Control
2.  Algorithms
3.  Application data.  Note the qualification on data. 

What this order means is that the effort to improve maintainability will be most effective when applied firstly to flow control then algorithms then application data.  Experience has shown that during the architecture and design phases of creating a program the order of importance is generally reversed.  That is to say that the most important thing to understand is the nature of the data to be processed,  then the algorithms (code) which will be require to process the data and then the conditions under which and the order in which the algorithms will be applied.

In keeping with the above definition of a program, the associated postings are generally organized into the following broad topics.  Each topic covers associated maintainability problems and ideas on to how to mitigate them.

• Documentation
• This is something of an anomaly in that it can be the simplest and the least volatile as well as the most difficult to do well and the most volatile.
•  Data
• This covers application data, control data and parameters.
•  Algorithms
• This mostly covers encapsulation considerations and is confined to application specific data manipulation.
• Control
• This covers control patterns and strategies
• Simple Controls (e.g. if, loop and case)
• State machines
• Simplified AI machines
• Multi-threaded Applications (might be considered a subset of Control)
• Mutlitasking
• Cooperative multitasking
• Interrupt driven multitasking
• Considerations for Object Oriented and non-Object Oriented designs