Simple complexity
Sometimes you have to write something based upon your experience and not so much on existing research. Whilst in the small hours of the morning your mind wanders and you start to think about things. One of those things was the recent update to the Grid format that I did for Moodle 4.0 and the struggle I had with understanding the Backup and Restore API, its complex and seems to have some quirks. And yet it is a part of an even more complex system, being Moodle itself.
If we take the TCP protocol which is logically a simple finite state machine that’s designed never to fail then we can investigate how it works and comprehend it as a whole. The same is almost true for the plug-ins I create, in that they should be comprehensible by a single person, although at times I do find that this is a borderline case in places when I’m scratching my head over a particular problem, but eventually do cope, or rather its the contextual switching between the different plugins that can be the issue cognitively. But if we look at enterprise level software that has many different aspects, requirements and use cases with multiple facets of supporting task based code, i.e. the building blocks, application programming interfaces, API’s, like file management, backup, user management etc. Then no one person can know or comprehend it all inside out once it gets to a certain mass. To then be able to create and maintain such a thing then you need a team of individuals with specialisms in different areas in order to make the API’s and additional code to make them all play nicely together and provide something that actually solves the overall goal of providing an electronic learning environment. That then leads to how the individuals or teams of individuals can be project managed with the software architecture as a living dynamic guide as to how each of the building blocks, components, fit together and interoperate with each other.
You can give them a free rein to just get on with it and create a solution within a loose set of guidelines with the guide. But then you end up with a set of really specialised solutions that whilst work within themselves, don’t play well with the rest of the system and is difficult to understand and worse than that, maintain. You could micro manage and control every aspect of their development, setting strict interfaces between the components, but this leads to too much restriction and stifles creativity, leading to a solution that whilst does the job, is not really the best solution that is possible, nor intuitive or easy to use by the user. What to do now? Well, you need to have some sort of human management solution that is the best of both worlds. Now, I’m not going to debate between the advantages and disadvantages of functional over object orientated methodologies. But I will state that I favour object orientation even if at the actual code level its functional, as long as the principle has been followed.
Why do I favour object orientation? Because it establishes a mindset that allows an individual to comprehend a problem to a solution. It’s encapsulated within itself, and whilst can still contain bugs like functional code, those bugs are easier to fix once tracked down, debugged, because their implementation code is all in one place and not scattered around, leading to lots of changes with the chance of more unknown side effects.
If we look at the natural world, bacterial, viruses and then consider ourselves and other complex lifeforms, then you wonder how our complexity interoperates and functions as it does. How do we really work? Or rather at times, don’t. Could it be down to how we are actually made up of all the much smaller and simpler biological systems that are layered upon each other, gradually getting bigger in size to form components that for the most part do play together nicely, and thus we survive and live. Now I’m not going to debate how this has come into being, my experience and expertise is in software engineering. But we can use what we observe in the natural world as a basis for how we solve computing problems. Not scarily, but already, like bacteria and viruses, which I believe are akin to what we create in software already, both in terms of methodology and implementation. But where we have greater control over its function and effect on us. By keeping things simple, not letting our egos run away by themselves, applying object orientation as a concept, and having a vision a that all stakeholders subscribe to, we can create and build complex systems that work and can be maintained effectively over time by more than one individual.
Disclaimers
Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.
Other names / logos can be trademarks of their respective owners. Please review their website for details.
I am independent from the organisations listed above and am in no way writing for or endorsed by them.
The information presented in this article is written according to my own understanding, there could be technical inaccuracies, so please do undertake your own research.
References
- API – en.wikipedia.org/wiki/API
- Backup and Restore APIs – moodledev.io/docs/apis/subsystems/backup and moodledev.io/docs/apis/subsystems/backup/restore
- File API – moodledev.io/docs/apis/subsystems/files
- Functional programming – en.wikipedia.org/wiki/Functional_programming
- Grid Format for Moodle – moodle.org/plugins/view.php?plugin=format_grid
- Object Orientation – en.wikipedia.org/wiki/Object-oriented_programming
- TCP protocol – rfcs.io/tcp
Conclusion
What do you think? Please let me know in the comments.
- Moodle 4 Security – A Review – 16th April 2024
- A little bit #fab – 16th March 2024
- Static framework – 16th February 2024
Fascinating post !
And so interesting in that reminding us that complex systems and alway constructed from smaller simple systems.
In nature the successful are the result of competition, and adaptation. I guess software applications are also similar 😉