In July I went to something called the European Innovation Academy. The idea behind the academy was to get groups of students together with the intention of creating a product or solution to a problem. (By product, think of ‘mobile app’ or digital service of some kind). As a part of a three week programme, students were taught about what is meant by innovation, introduced to concepts such as user centred design and different business models, before being presented with some talks about how to further develop their ideas. At the end of the third week, participants were encouraged to write a short pitch to sell their product, solution or service, to potential investors, with a view to securing further funding.
Making skills visible
A couple of months earlier, I went to a UK Higher Education Academy event (blog) that was all about how best to go about the teaching of programming to those students who want to learn how to develop software for mobile devices. What struck me was the point that if students want to get ahead, a really good idea is to create some kind of product that could be sold through vendor app stores (such as Google Play, for instance). The advantage of doing this is that you advertise your skills in a very direct way and can clearly describe what you’ve done and achieved on your CV.
A substantial part of the academy was all about creating something. As far as I understand it, there was time on the programme to allow students to not only learn about different platforms and tools, but also time to try (as best as possible) to create some prototype software that could be demonstrated to others. Creating an artefact, as far as I could see, was considered to be a really important aspect.
Taking software further
A number of years ago, I used to have a job as a professional software developer. It was thinking back to these times that I asked myself a fundamental question: ‘what on earth could I potentially say to the participants to help them appreciate some of the challenges inherent in creating software systems and products?’ I’ll put my hand up and say that I’ve always had one foot more firmly in the technology side of things than the business side.
I struck on an idea to not only talk about software, but also some of the more human sides of software development. Software is, of course, a creative product, and there are things that we can do (in terms of structuring things to help people work together) to get things done. The things that we choose to do, however, are fundamentally affected by the types of product that we’re creating. Some products or solutions require us to use different methods.
So, what did I talk about? I had three hours to fill! Below is a quick summary of what I considered to be the highlights. The participants might have different views.
First of all, I asked the groups some questions to help them consider what they considered to be the most important or significant challenges that they felt they needed to address. When you’re going head long into a development, I thought it might be useful to find a bit of time to step back and ask the participants about the problems that they were facing, and whether they might be able to share some advice about how to solve some of their problems and how to manage some of the risks that each project group might face.
Since the participants were creating prototypes, I talked a bit about the process of interaction design and the ideas of different types of prototypes (i.e. horizontal prototypes and vertical prototypes). I also spoke about the necessity to consider the user, the task and the environment, since considering all these aspects are really important when considering the final usability of a system (and usability will fundamentally influence whether or not a product or idea is accepted).
You could argue that interaction design is all about process. I also introduced the idea of software development processes, notably, agile development which emphasises regular and constant communication between both developers and stakeholders. I made the fundamental point that constant communication is a necessity since software is an intangible product; the only way to make software real is to talk about it. Agile methods facilitates that talking.
In some software development cultures (and each culture is slightly different), software testing can be an integral component, but it is a subject that can be very easily overlooked. Software testing is a pretty big subject, covering a huge variety of different techniques and approaches. When we move from the small to the large, we fundamentally need to make sure that things work as they should be (since if things go wrong, then our customers don’t get a good customer experience). I spoke about two important aspects to testing (and highlighted a bunch of others). These were: different types of usability testing, and test driven development.
Abstraction is, perhaps, one of the most important and fundamental concepts in computing. An abstraction could be described as an essence of a concept which doesn’t contain any superfluous detail or ideas. When our abstractions are right, our software becomes easy to work with. Abstractions represent a really important way to manage complexity. We need abstractions within our code because programmers can only deal with a limited amount of stuff and connections between parts of a program at any one time.
One approach to creating software is to create our code in different layers. Software developers constantly use code libraries as well as consume data from other information sources. When talking about abstractions I also introduced the idea of design patterns. These represent templates of common solutions to coding (and software design) problems that have been shown to occur time and time again. Coming back to the point of processes and the need for constant communication, if we can put a name against our various types of abstraction (which is something that the concept of a design pattern does for us), this can make the communication between developers a whole lot easier.
When you’re working with code things can get very complicated very quickly. There’s multiple files, different versions of libraries, you might include a whole bunch of different graphics or change database structures or web services... and then the bugs start to creep in and give both you (and your customers) a whole set of headaches.
I felt that it was important to saying something about version control and configuration management. When we’re in the zone of high productivity (when we’re at one with the problem and our tools), creating new products and services, we can quickly lose our own history in the path of continual change. Version management systems (or whatever you choose to call them) enable some aspects of development history to be captured and saved. One challenge that we need to be aware of is that the use of these tools requires discipline.
To create any software of substance, you’ve got to use some technology that already exists. If you’re creating apps, you’re going to use some kind of integrated development environment (which consists of programming languages, debuggers, code profilers, and a whole bunch of other goodies). Another subject that I wanted to mention was that there is a whole set of other technologies that developers could use.
One really useful concept is the software framework. In essence, frameworks can be considered as a set of high level abstractions that allow developer to more efficiently solve common problems. A framework can allow you to work more quickly (and hopefully more efficiently) by building on the work of other developers. Two challenges include: figuring out which framework to choose (and whether it really would help you or not), and then understanding how a framework might work.
Another broad set of technologies that developers might utilise is web services. Web services can now be used to store data and host applications. Rather than having to manage their own servers and systems, an app developer might be able to use services that have been developed and deployed by other companies. The challenge lies in figuring out what they are and making choices between different possibilities.
In terms of software, the word community can be interpreted and understood in a number of different ways. There might be a user community or a developer community, for instance. You might want to share information about an emerging product through blogs and direct interested users to these updates through Twitter updates. My point was that community, whatever form this might take, is fundamentally important. Although technology is a necessity, technology won’t develop, change or improve if there isn’t a community of users or developers that are keen on using or enhancing a system.
Another notion of community lies with the area of open source software. I understand that during earlier parts of the academy, students were introduced to different types of business models. Some business models work through the use, application and development of open source software. In some situations, open sourcing a development might be a part of a wider strategy. If so, then it is fundamentally important to consider how to support and nurture a community that makes use of any software (or service) that is made available to others.
A final connection to the notion of community that came to mind was the importance of partnerships. Creating effective software and services is something that requires a lot of specialist skills and expertise. I remember one story from a HEA event that I attended some time ago. I remember being shown an example, a collaboration between a graphics artist and a programmer, that led to the development of a really nice product; an interesting and playable mobile game. A fundamental point was that sometimes, the best work that we do is when we work with others.
A personal reflection is that putting together these series of talks seemed to take up quite a lot of time, but it was pretty good fun thinking about what to include and what not to include. I asked myself a really simple question, which was, ‘if I was there, being a delegate as a part of this programme, what would I really want to know?’ In retrospect, I fear I might have perhaps crammed in too much material, perhaps covering too many ideas or too many technologies in what was a very short space of time. On the other hand, I think this was the point of the programme: to introduce people to new concepts and ideas, and to allow those on the programme to be fundamentally challenged.
One thing that struck me was that some of the teams gave the impression that they needed more developers; more people who were able to use the software development environment to create new products. If you’ve never seen an integrated development environment before, the learning curve is practically vertical - it takes time to appreciate their intricacies and idiosyncratic ways. Three weeks is an impossibly short time to come up with a new innovative idea that actually does something if working with technology isn’t something that you do all the time.
Since I attended the programme during the third week, I wanted to positively tantalise the participants. I wanted to say to them, ‘you know, all this tech that you’re playing with, and all these cool prototypes that you’re creating using tools that you’ve never used before? Well… this is only the beginning – there’s a whole bigger world of software tech out there ready for when your ideas and inventions become real.’ I hope I managed to expose some of that bigger world of software to some of them.