Should we change the way software skills are taught?
Posted on 10 August 2015
Should we change the way software skills are taught?
By Alexandra Simperler, Institute Fellow 2014 and NSCCS, Imperial College, and Katalin Phimister, Computational Chemist, UK.
In today's fast moving world, the number of electronic tools, programs and applications are ever increasing. People see them as a black box something that just works. They overlook the coding, configuration and setup that has been done by a team of developers. Does this prevent people from being proficient and effective users of the software? We want to start a discussion on this point by outlining some scenarios from our professional lives.
People are central to the way software skills are taught. Many users first come into contact with software tools during their university years, but others only start using them after working many years in industry. Those who are exposed to computational tools during their university years often have time to study it for years and familiarise themselves with the details of the algorithm. In industry the situation is different, time pressures often mean there is an immediate need to apply the software to real project work. This is why contemporary software training is focused on two questions: how can we aid the users' research/analysis, and what is needed to just make it work?
Thus, a typical user training session often comprises a journey through the user interface using a simple input, running a calculation and analysing the output. An input (in our field) is usually graphical in nature and may range from a simple ball and stick model of a molecule, to a protein sitting on a gold surface. The software (and therefore the developers) help the users by providing databases of the most common structures from which the users can pick and choose, select an appropriate method and set a required accuracy level to generate their results. Once the calculation is complete the output is often visualised in a graphical format. The consequence is that the user is isolated from the direct results of the algorithm: the result files and the log files.
One primary focus of most software developers is to make their product as user-friendly as possible. Typically by shielding the user from having to know all the fine details of the algorithm before they start using the tool. This is extremely important as a positive initial user experience aids learning and is the first - essential - step in engaging the user. However, as the user progresses it becomes more and more important to support an understanding for how to start troubleshooting problems when they – inevitably - occur.
What we would like to impart is an under the hood understanding of what the software is doing, which will give the user more power. How is the science or scientific experiment coded in computer terms. What do we really ask the computer program to do when we click Run? What changes when we choose quick scan rather than detailed analysis? We see this lack of understanding manifest itself in support questions which occur because users are often not aware how an application really works. Would teaching a better understanding of what it takes to develop and provision software improve the users efficient and effective use of the software?
Should we start from first principles? Probably not, as this removes the user even further from the application and takes too long to be feasible. We should invest in designing problems which are relevant to the majority of users, that illustrate both how a problem is solved and the result of that solution, and what steps the program takes to get there. We also need to choose examples to demonstrate which parameters are most likely to require changes in the future.
We need to focus more on what a program is actually doing and how it was designed, because this understanding helps users to avoid common pitfalls. If they encounter problems, they can more effectively question their own approach and hence better tailor their questions to support and training teams, which allows relevant help to arrive in a timely fashion. Understanding the logic behind the software is key to turning beginners into competent and productive users of the software they are being trained to use.
We want to change the way in which software skills are taught, especially in relation to novice or time-pressed users. Teaching an under the hood understanding of what the software is doing is key to producing advanced users for the future. We would be delighted to hear your views.