The principle of changeability defines the possibility to change the functionality of software components with as little as possible impact on other components and without having to change the architectural structure of the solution.
Software will change over time, and the anticipation of change drives many aspects of software construction; changes in the environments in which software operates also affect software in diverse ways.
Change cases describe how the system might change in the future, and can be functional or nonfunctional. Examples of change cases to take into account are modified business processes, new technologies, integration with other systems, volumes of users.
Some practical aspects to assess changes against cases are potential benefits of the change, probablility of the change case becoming real, relative priorities.
If you address changeability in the software system being developed, you will need additional efforts to provide an extra degree of flexibility, extensibility, and scalability to support future change. The cost of the extra effort to construct more changeable software, or already anticipating future changes in the solution, must be weighed against the priorities, and the future cost the change to the software.
Applying principles for construction such as Abstraction, Encapsulation, Isolation, Layering and others will deliver software that is generally more robust to change.
It’s not my rant, but once you think about something a a certain way, you tend to find more support for that opinion.
Vincent Cerf: AI Is Not An Excuse!
Read de-mystifying and un-hyping discussions on AI.
(I felt sorry I looked at deep learning as algorithm from the 1980s/1990s that were suddenly executable when the hardware developments (GPUs) caught up.)
The deepest problem with deep learning – and the links in there.