In a lot of cases a piece of software starts as a clean and simple idea that gradually grows into a much larger body of code as it is enhanced with various functionality and features.
Usually when the original idea has to be modified or enhanced it is performed on the most recent version of code that already incorporates mutliple layers of the said process of growth. My point of view is that at least in some situations a better approach is to
- return to the original clean version,
- adjust it in the most natural way (without being constrained by the tons of later changes) and
- repeat the previous growth process from the new starting state.
Ideally, the last step should be as automated as possible.
In this post I will maintain a list of those growth dimensions that are common to a wide range of applications regardless of whether they are good candidates for automation or not.
Fool-proofness
The proof-of-concept version is usually written without any error-handling in mind. During productization, fool-proofness must be added.
The next item can be considered a variant of this one, still it deserves being mentioned separately (after all, there is an entire sub-industry focusing on it).
Security
The effect of this one can be as little as zero (when we only need to make sure that there are no buffer-overflows and similar bugs) to quite extensive and pervasive (if we are concerned with various permission levels for different users).
Internationalization
Support for multiple languages, units, currencies, etc.
UX & Accessibility
Optimization
Replacing straightforward yet slow data structures with complicated ones can result in much larger code. Sometimes a significant optimization is impossible without a drastic change in the software design.
The next item can be considered as a variant of this one, still it better be split out.
Support for concurrency
- Asynchronous IO
- Multithreading
- Multiprocessing/distributed processing
- Off-loading computations to the GPU
Compatibility
- Backward compatibility
- Forward compatibility
- Compatibility with another existing tool
State persistence
- Save & open/load
- Versioning/checkpointing
- Undo
Interactivity/Scripting
A batch-mode or CLI application may need to be converted to an interactive one (e.g. via a GUI or integration with a scripting language).