Scholarship Technology in Year 13

For some reason I love giving myself impossibly difficult projects to work on. In year thirteen, this meant that on top of all of my numerous extracurricular activities, I would also embark on the journey of frustration that is a Scholarship Technology project.

Let’s get one thing cleared up right now: I have absolutely no regrets about doing Scholarship Technology. It was a great challenge! I really enjoyed the experience of working on a project that spanned months, rather than weeks, days or even just hours. I learnt how to program in a new language, with a large framework (Java + Android), I learnt what it’s like to develop a native Android app, I met a lot of interesting people who helped me out along the way, and I built a thing from start to finish.

Starting that project was difficult. During the first couple weeks of year 13, I asked my digital technology teachers if I could do scholarship technology. At this point I was already signed up for scholarship statistics and calculus, so I had the attitude of “why not just throw in one more?” My teachers were upfront. They said that scholarship technology is hard, they have no idea what the markers are looking for, and they have had very few successful scholarship technology students from our school, across all the technology disciplines, not just digital. But for some reason, I signed up anyway!

I love a good challenge, something that will push me right to the edge with frustration, something that I have no experience in whatsoever and therefore maximizing the amount of stuff I have to learn! This is an excellent way to sum up my experience with scholarship technology.

The first thing I did was look over all the example projects that my teachers could find for me. They were cool projects for sure, but none of them actually matched up with what I wanted to do. However, they were very useful. Turns out it’s not important what your project actually is, it’s about the process you go through. All the projects I looked at followed the same structure:

  1. Identify a problem
  2. (Hopefully) solve the problem

Identifying the problem

First thing you have to do is decide what it is that you actually want to work on. Pick something you’re interested in! You’re going to be spending a lot of time thinking about this project, so might as well make it something you are going to be able to enjoy. For me, it had to be something I could solve with programming and like I said earlier, I like challenges so I wanted to do something in a language that I hadn’t actually used before.

The problem that I wanted to solve was that it’s too hard to keep up to date with how you’re doing in NCEA. I was going to make an app that would help high school students with this task. It’s fairly obvious how I came up with this idea: keeping track of NCEA credits is hard. Despite many visits to various app stores, I just could not find an app that did what I wanted it to do — so why not make it myself?

I used the first term as a time to set up the project. The only decisions that I had made at this point was that I was going to be creating an Android app, so I got to work on learning Java. This is largely what I spent my time on in the first term, I did a little bit of brainstorming on my project, but most of my time was dedicated to Java. The first couple of programming languages you learn are always the hardest (after that it’s considerably easier to pick up new ones), and having come from a Python background, Java was very different. I managed to get my hands on a copy of Otago University’s Java textbook for NCEA, their Python textbook was invaluable for learning Python, and the Java one was even better.

After the first term, I decided that I’d had enough and that I actually wanted to start working on my project. Somewhat ironically, now that I’d learnt enough Java to be able to write programs with reasonable confidence, it would be put on the back-burner for a while. Meanwhile I was working on designing the app, this is where the research phase comes in.

Solve the problem

Ok, this is the hard part.

Does the problem actually exist? Is there a solution already in place?

Before I got too far ahead of myself, I did some market research. It’s important to establish that the problem you are solving does actually exist! The research at this stage involved looking for any current solutions to keeping track of NCEA credits, and checking if other students wanted the app that I was proposing.

“Market research” wasn’t just me asking my peer group at lunch what they thought. I wanted to get more accurate results, so I wrote surveys and gave them them a wide range of people. Even creating a decent survey is a whole science in itself (enter my interest in statistics and psychology) so this was a relatively time consuming process.

Who are your stakeholders?

Very early on (with the market research phase perhaps) you have to decide who the stakeholders are. A basic example is that an app you make for a three year old is going to be very different to one you might make for an 18 year old. So I did some further research about who exactly was going to be using my app, and I kept them in mind the whole time. It’s so easy to think your product is perfect because you can easily use it, which is ridiculous, of course you know how to use it! You made it! Hence identifying stakeholders.

The stakeholders are who you are designing the product for. I like to split them into two groups: direct and indirect. “Direct” stakeholders are those who you hope to use the product the most, for my project the direct stakeholders were students taking NCEA courses. “Indirect” stakeholders are people like parents, teachers, etc. Basically they are people who might not use the product themselves, but who might advocate the product to their kids/students.

One of the reasons that it is so important to have stakeholders is because you want to include them throughout the process. When you’re designing your product, you want frequent feedback from them. What makes this difficult is that sometimes you get feedback that conflicts with your own ideas! Unfortunately sometimes you think you have the best idea ever, but it just makes more sense to go with what the user wants.

Designing

Alright, you’ve established that there is a need for your product, and you have an idea of what your stakeholders want. It’s time for a brainstorm.

This was one of my favourite parts of the whole project! One lunchtime I went into an empty classroom, armed with a couple of whiteboard markers and just wrote everything down that came to mind. At this stage it had nothing to do with appearance of the app, and everything to do with how it would behave. What I mean by this, is I basically tried to summarise what the user should see when they first open the app, and from there what they should see when they press each button, and what happens when they press a button on those pages, etc, and thus a giant flow chart was born.

I took a photo of my giant brainstorm, and the next day I turned it into words. Then I did it again. The second time I was able to go a lot more specific, because I had decided what states/screens the app would have, so it was more a matter of deciding how things should be arranged.

Minimum Viable Product

Now that I was armed with stakeholder feedback and a couple of brainstorms, it was about time I decided what my MVP (Minimum Viable Product) would be. The MVP is basically your fall back. It’s your “I should at least get this far” goal. It’s good to have an MVP because it gives you a product that you know you can create. When you design your MVP, at the same time you should also write down things that you would implement next - consider these your stretch goals.

Creating

Finally! We’re at the let’s-actually-make-something-now part! But I actually slumped back into a design phase after only about a week of working on programming the app. It didn’t take me long to realise that sure, I had designed how the app would behave and I had a vague idea of how it would look, but I missed a really important step. What was the infrastructure going to be like?

Back to the whiteboards! Having no experience in app design whatsoever and now suddenly having to work on the full stack (i.e. Android framework on Java, database design, user interface, the whole lot!), meant that I suddenly had a lot to learn. At this point it would have been easy to just stick with the code and keep trying things out to see what happened, but you’re effectively just setting up to shoot yourself in the foot. Planning saves you so much time. For most NCEA standards in programming it was incredibly annoying and felt unnecessary, but this project was considerably bigger, so spending a few hours planning beforehand would save me a lot of pain later on.

Testing Techniques

There are two sides of this: the first is with people, the second is with code.

So the first test I did was actually not with a phone, instead, it was with paper ( “paper prototyping”). What I did was a made a mock of the app using paper, and everything was to scale. I then gave this to stakeholders with my original plan of how things would be arranged on the app, and asked them to try using the “app.” Whenever they pressed a button, I moved the the pieces around to show the next page. I did this because coding the first mock would take a while, and this was an easier way to get an idea of the immediate design problems the app would have. This also meant that I would be able to show the first app version to the same stakeholders without them being immediately familiar with how the app works. This approach worked remarkably well, and helped me to refine my design before implementing it with code — considerably easier than writing code and then going back and changing it.

Like I said earlier, it’s important to get feedback from your users, so test often and ask them lots of questions. It’s also important to note that over time your users may start to become familiar with the product, so make sure you change who’s testing your product at each testing stage to make sure that it’s still intuitive for a new user.

Documentation and Decisions

So this project is heaps of fun, but remember you are also submitting it for assessment, i.e. you have plenty of documentation to write. Every decision you make in every stage needs to justified and documented. Whether this goes into your final submission or not is irrelevant, at this stage, this is for your own benefit. Save yourself the pain of later on thinking “why did I do that??”

Getting into the habit of forcing yourself to justify every decision means that you start to automatically think about the impact each tiny little step is going to have in a week’s time. A little bit of research now goes a long way.

Part of the decision making process involves talking to other people. No this doesn’t mean you need to get confirmation before every single line you write/nail you hammer/wire you solder, just for the bigger things. Sometimes this is a matter of talking to a wall because as you explain it out loud it suddenly all becomes clear, and sometimes you actually want to talk to an expert in the field (or at least just someone who’s worked on something similar). For me, I reached out to a number of people. I contacted computer science professors at the local university, had meetings with people from local app development companies, and talked to a number of friends in the tech industry. Sometimes this was to learn about the app development process, sometimes this was literally for “my code’s broken and I don’t understand what I’m doing wrong.” These people were invaluable to the completion of the project.

Towards the end of the project is when you can figure out what you actually want to put forward for submission. I ended up with nearly 50 pages of work to submit, but please don’t use that as a guide for how much you have to write. It varies from person to person. I strongly believe in “quality over quantity,” but I did a lot of work on this project! So turns out those 50 pages were what I needed to comprehensively report on my project.

Illustrate how your process matches up to the real world

You have a cool opportunity here to work on a project which can match up with something someone would actually work on in industry, so make sure you identify what approach that “someone” would take. Coming from an engineering perspective, this means understanding the difference between waterfall and agile project management approaches (and everything in between). Part of this was learnt from reading, most of it was learnt from talking to professionals in the industry.

Get feedback often

Yes, this is an individual project, but you can still include as many other people in it as you want! I had two teachers actively involved with helping me with my documentation, someone from a university helping me to understand user interfaces, and about three other programmers who jumped in occasionally to help me understand how to code for Android.

Time invested

Basically this was treated as a whole other subject, and then some. It was my highest priority, mostly because it was super interesting and fun to work on! I spent hours on this every week to get it as close to perfect as I could. I don’t know how this would compare to other people, but a large amount of my academic life was spent on this one project. Teachers wont like to hear this, but I actually missed a lot of school time for this project. Some days I would miss classes in order to spend more time at the university to get feedback on my progress. But of course when I got back, that school work was always there waiting for me, so don’t go thinking that you can use this as an opportunity to skip school because believe me when I say it’s not going to work out like that.

Dealing with disappointment

So about 3 months into my project, someone else released an app that did exactly what mine was going to do. This was disheartening, and it sucked. Then I realised that this probably happens in industry all the time. It’s a competitive market, so you just suck it up and move on. I did consider pivoting, and working on something else, but I was kind of enjoying working on something that I could actually use once it was finished.

tl;dr;

In case you’re wondering what the outcome was, I won the scholarship. But by the time I finished the project the scholarship didn’t really matter, it was what I learnt that made the whole thing worth it. Across the course of that project I learnt about project management, a whole new programming language, how to create (or possibly how *not* to create…) a native Android app, and I made a lot of great industry contacts.

That project was a huge test of my patience. Learning Android development was hard, and doing it by myself (no one in my peer group at high school were into tech) made it that much harder. Although I kept a great attitude across the whole project, admittedly, there was one day when I felt like I had bitten off something far too big. But my friends picked me up and my teachers reminded me that it’s all part of the experience. I definitely couldn’t have gotten through that without that support.

It’s difficult working on something where every tiny little increment requires so much work. It gets a little bit disheartening, and a little bit tedious, but (here comes the cliche) in the end you look at what you’ve made and you realise how much you learned, and you have no regrets.

So if you’re considering taking on scholarship technology (or maybe just a large project in general), then you’ve got your work cut out for you. No point in hiding that fact, if you don’t like hard work then this isn’t for you. But if you love to be challenged, pushed to your limits, and having legitimate academic excuse for not going to your physics class, then this is for you.