What exactly is ‘Development’? In this post I’ll describe what it means to me within the context of ‘Software Engineering’. However, you could equally apply my thoughts to eLearning course construction.
I am independent from organisations mentioned and am in no way writing for or endorsed by them.
Names / logos can be trademarks of their respective owners. Please review their websites for details.
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.
What is ‘Development’?
Development is the ‘Art’ of solving the ‘Problem’. It is a combination of the skills, talent and knowledge you’ve acquired from processing the data into information you’ve received over your lifetime.
Notice that I’ve started off with just the word ‘Development’, thus it can be applied to the process of creating anything new. You’re ‘developing’ something that has not been or not done in this way before.
Two sides of the same coin
When developing Moodle plugins, there are two key critical elements of knowledge that facilitate this:
- Knowing how to develop in functional and object orientated ways using the languages that Moodle uses.
- Understanding how Moodle works on a programmatic level.
This is not quite ‘Chicken and Egg’, but in order to gain the second you need the first, which in turn relies on having a purpose, the second. However, you can begin to learn the first by using simpler, more trivial problems to solve. This then gets you the entry point upon which to access the second, then in a cyclic fashion, you can evolve and improve over time.
The first is more generic and the second, more specialised. But one cannot exist without the other when developing and making Moodle work.
And here in-lies what makes software development so difficult at the start. You have to do so much and iterate over both sides of that coin before you see results that can make a real difference. And this can be disheartening, but you have to persevere and carry on, knowing that you have a goal that you want to achieve.
Quantifying the problem
Most of what I program is ‘bespoke’, its new and solves a problem within the constraints of a given area, its ‘context’. That does not mean that it has not been solved before, but it does mean that it’s not been solved within the context to which it belongs. This makes it difficult to quantify how long it will take me, and often I only know that after I’ve spent between 30 to 60% of the actual known time solving the problem. And even then, that is not an exact science, but one drawn from experience with a bit of guess work.
So when asked ‘How long will it take?’, I genuinely don’t know the answer, but instead have to:
- Consider the problem and break it down into functional elements.
- Look at what is already there and what could support each element.
- Think about what I’ve done before that might be similar, think ‘AI’ without the ‘A’.
- Come up with a solution design.
- Investigate if the existing code needs to be ‘refactored’ to support the potential solution I’ve thought of.
- Create a plan of how the solution could then work and integrate into what is already there.
Then and only then, will I have an idea within a reasonable degree of certainty if the proposed solution will solve the problem. That ‘degree of certainty’ invokes a ‘level of risk’ which places a value on the task. If the risk is too high with a good chance of failure, then I may decide not to undertake that task because I’ll spend lots of time and get nowhere. And additionally, not even see the potential to reuse elements of the solution at a later date because they would be too specific and unique to that problem.
Over the years, my development experience ‘as I’ve iterated over that coin’ has improved. What was once ‘high risk’ is no longer, and I’ve gained confidence in what I’ve learnt in other lower risk problems or simply using my own time to experiment and learn new things. Which in itself is ‘low risk’ as you’re just playing with your test system and if it breaks, then what the heck, it doesn’t matter.
When I learnt PHP, I did so from a Java / C++ / OO background, so that experience was my ‘entry point’ into learning how PHP and indeed OO PHP worked. Your ‘entry point’ is the starting point where you have the backing of what you already know as a basis of learning something new.
From a learning Moodle perspective, you’ll know how you want to educate and will have a collection of resources that support that. The key is understanding how Moodle can present your resources in a more user friendly way rather than just uploading files and using Moodle as a ‘file management system’. Then over time, you’ll improve the courses you create from the feedback you get from your students and therefore gain experience, resulting in improvements to the courses you create and maintain.
But ‘why’, why go to all of this effort? Well, because its ‘there’, its ‘new’ and not been done before. For the ‘challenge’ and then sitting back and admiring the artistic beauty of the solution. Yes, indeed, code can be beautiful when you understand its syntax and can see what its doing.
That doesn’t mean that all solutions are beautiful though, you will end up with code that looks like a complete mess. Just like as an experienced educator, you know if a course has been designed well with excellent resources.
This post is in actually, a collection of loosely connected thoughts on the subject. However, they all are related and connected to form an overall skill set that facilitates problem solving in a software context. I do hope that you can see the connections between the thoughts could relate to your own experiences of solving real world problems in your area of expertise.
What do you think? Please let me know in the comments.