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.
In addition to the tweaks to support BTRFS, this guide also includes some tweaks for issues related to slow boot times and partitioning.
Poverty: A problem of complexity? 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.
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:
a system could be built that simply doesn’t meet the requirements of the sponsor. a system could logically solve a problem, but exhibits behaviour that is outside of operational tolerance once deployed in a realistic context. a system could simply remain in development indefinitely and never finish. When the “surface area” of the system is large it simply becomes more difficult to avoid all of these failure modes simultaneously.
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.
Why is this a problem? 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.
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.
Resources are limited. This is in many ways one of the defining realisations of our current age. We have limited oil, limited land, limited water etc.
In general system design this is no different. For computationally backed systems we have limited execution cores, limited volatile memory, limited network bandwidth. The realisation for software engineering is that the systems being built can not be built with the mindset of unlimited resource, but rather with the view that resources are bounded.