Convex: An Apprentice’s Perspective
Charlotte is a Frontend Developer for the UK Advanced Digital Engineering (ADE) Software team at Arup.
Rory is an Apprentice Developer for the UK Advanced Digital Engineering (ADE) Software team at Arup. He is currently halfway through his degree in Digital & Technology Solutions at Queen Mary University London and splits his time between the course and working at Arup. Recently, we worked together on developing Convex. I sat down with him to talk about his experiences on the project.
Let’s start at the beginning. What is Convex? How would you describe it?
Convex is a website that’s designed to promote the use of concrete in wave energy devices. It allows users to enter certain details about their proposed device and then it will calculate values relating to the technical feasibility, cost and carbon impact of using different materials to build it. It also gives you more information about why you should use concrete and how it would work in reality.
What was your role in this project?
I was a frontend developer on the project and I was largely working on a lot of the calculations done within the tool. We had a team that was made up of a Scrum Master, Product Owner, Designer and a couple of other frontend devs. As it was a frontend only application, we didn’t need any backend developers.
I’ve worked on projects using Scrum before but I wasn’t really integrated with the whole team, so being part of a team like this was a really positive experience. We were in close contact throughout the project and had regular stand-ups. Being able to ask anyone a question at any time was great and really sped up the whole development process.
What did you enjoy about working on this project?
The main thing was that this was the first large Angular project I had ever worked on. I already knew I liked Angular before working on it as I like more opinionated technologies and this project really proved why using a framework like Angular works so well. The structure of the app was much easier to understand, and once we had planned it out, it was straightforward to build.
This was also the first time I’d worked with Scrum properly and it was a really good experience. It’s one of those things that you often talk about doing but then on a lot of projects it isn’t implemented properly. Splitting up work into sprints and being able to show working software increments to the client on a regular basis and getting feedback felt good. Also, assigning work based on the time estimate of the developer carrying out the task meant that the whole project flowed really smoothly as we were realistic about what we could get done. We overestimated a lot at the beginning, but after that first sprint we adapted very quickly to plan our work better.
Working with multiple devs was really good too. If you have a question about a new technology, like RxJS for example, it’s great to be able to ask someone without taking their time away from another project. Working with other devs on the same project also means that they have all the context when you want to talk about (or complain about!) something you’re working on.
What was challenging about working on this project?
I don’t know if I’m looking back on everything rose-tinted, but I’m struggling to think of challenges. One thing that was challenging was getting used to part of the Scrum workflow. Remembering to do time logging and updating the statuses of issues on Jira was difficult in the beginning, but the more you do Scrum, the more you build up these habits.
What will you take away from working on this project?
I think the main take away that I had is that it’s always good to plan ahead. We fully architected out the application before starting work on it which really helped. This lesson, however, applies even down to the level of how a function will work. With one of the calculations I just jumped into writing the code before actually thinking about ‘how is this going to be interacted with?’ Later on this caused me some problems, and I could have avoided that by planning ahead.
Another takeaway is that there is actually time to do testing on projects! I think one of the main barriers to implementing testing is ‘oh we don’t have time for it, it will take too long’, but if you start writing the tests as you are writing the functions, it doesn’t add much time at all and significantly increases the quality of the code. Committing to our standards together at the beginning of the process also helped us to support each other in keeping to them.
Any closing thoughts?
Overall working on Convex was a really positive experience. When someone asks, ‘What do you do?’, I can be like ‘Hey, look at Convex, this is what I do!’.
You can check out Convex for yourself here.
Find out more
If you would like to learn about Digital at Arup meet the team, and read more about our work here.
