One of the more difficult problems in software development is “naming.”
As the adage goes: “Naming is hard.”
We really have two different problems:
Based on the work by Saltzer, we can see the guide to the first question is that:
That is, to preserve identity under some set of changes. Or, worded differently, to borrow from John Day’s synopsis:
Upgrading software is a common part of our lives. We bemoan upgrades of apps on phones that change features we had just come to enjoy. We wait for upgrades of applications on our laptops to finish installing. We dread operating systems upgrades that might break things. We gloss over notifications of upgrades to online services. And we joke about upgrades in the more corporeal aspects of our lives. All the while wondering and debating as to when the next new feature will be included in upcoming upgrades.
Working in a corporate it is common to hear the call for innovation. Businesses know that an important part of their success in the market place is to be able to innovate. Yet all too often, these organisations find it increasingly difficult to innovate. By thinking about evolutionary processes or about systems it is possible to offer some possible, albeit unsubstantiated, reasons for the difficulties, and some possible remedies.
Let’s start by considering a timelapse view of a business concern.
This guide provides amendments to the original scripts by Paddy Landau, so as to provide the option for using BTRFS as the root file system. These changes have been collated into a modified version. Please note, the modified scripts still depend on the ancillary scripts provided with the original script.
Poverty is a global problem that affects our civilisation on a large scale. However, what is poverty? This is an important question, since very often the very definition of a problem guides the process of finding solutions and informs the type of the solutions that are considered.
For the problem of poverty, there are many definitions. Very often these definitions tend to focus on income and money. One only has to look at the opening sentence on Wikipedia to see that poverty is commonly cast in material and economic terms:
We have become increasingly aware that we are living in an interconnected and interdependent world. This is generally related back to the field of study of “Complex Systems” and includes terms such as: complex adaptive systems, emergence, chaos, non-equilibrium systems, network effects, and so on.
An interesting formulation that helps to identify, in soft terms, the nature of complex systems is VUCA, that is systems that exhibit the following properties:
In this post we consider the situation of a long running engineering project and see how taking a hypothetical, but explicitly, model driven approach could help to guide the undertaking to completion.
Firstly, what is a “project”?
This may seem like a obvious question, but the definition is important, because all too often in organisations the colloquial understanding is something like:
A project is a catch all for stuff related to that thing that somebody somewhere wants and that is going to need a bunch of people and time.
Monolithic undertakings tend to fail. This may seem like a harsh statement, but there are many ways for systems to fail:
When the “surface area” of the system is large it simply becomes more difficult to avoid all of these failure modes simultaneously. The odds of success diminish multiplicatively as more dependencies are added to the chain.
When taking a model driven approach to software development, one of the problems that arises is that of how to synchronise the model with the reified implementation.
Put more bluntly:
How do we know that the final software accurately implements the model.
Providing a bit more context, while software modelling is not new e.g. UML, MDA, EMF and other TLA approaches, we are focusing on using conventional software languages and tools. These models are then built as standard executable software.
Development of large scale distributed systems is complex. Many of our software systems essentially follow this distributed system pattern, and are therefore complex undertakings.
Complexity takes time. It takes time to evolve in nature, and it takes time to introduce in software. Complexity also introduces risk. This risk can generally be sufficiently mitigated with the inclusion of additional complexity so as to reduce the likelihood of systems failures – but then even more time is required.