How I Started Working on a Personal Project — Part 3

This is part 3 of my thought processes and learning points from the development of my personal project. If you’d like to read part 2, you can read it here: https://medium.com/@keloysiusmak/how-i-started-working-on-my-personal-project-b4a8b7ce13a7

In this post, I wanted to share more about the development of the web application, and eventually why I decided to give up on its development.

I started developing this personal project with the intention of making it a web application. Having come from building several LAMP applications, I was extremely comfortable with building web applications and I always envisioned this project to add to that collection.

Why Web?

I decided to build a web application because it was the fastest for me to build a MVP. It was the quickest way to deploy a working prototype of the application, and also a good practice for me to refresh my skills and adopt React / Angular / Vue as an alternative to the PHP frameworks I have come to love. I was a proud user of CakePHP, CodeIgniter and Lavarel in the early part of my software engineering journey, building several of such websites for clients and personal projects. CodeIgniter was one of my favourite ones, it made life very easy for me and allowed me to quickly churn out websites for clients.

Familiarity with the web environment meant that I once again had access to the familiar way a web designer thinks — flex-box, bootstrap’s 12 column system, mobile responsiveness, it was all familiar territory. I didn’t have to relearn the basics, and could spend time working on enhanced functionality.

I wanted to make the most out of building yet another web application, and decided to focus my time and energy building a web application that packed functionalities. I didn’t want to waste precious time tinkering about with UI elements, or working on bits and pieces that had little to do with presenting a decent MVP.

I wanted to work on meaningful functionality, functionality that would go a long way to help solve some of the toughest problems about weddings. Some of the interesting ideas I had in mind, was for example, how to solve the seating arrangement for guests, given a plethora of constraints.

For instance, it is easy to find a way to sit 270 guests onto 27 tables.

Now consider that some of them come in groups, the Wong family had to sit with each other. And consider that pair(s) of your guests refuse to sit on the same table with each other. It gets better.

Now consider that some tables are “higher priority” — they offered a better view of the aisle and the reception, and you’d want your family members to take those seats.

It sounds extremely complicated, but by reducing the problem to a satisfiability problem, this can easily be solved with a SAT solver.

Functionality such as the SAT solver above are interesting and unique solutions which I hoped to bring aboard the platform in the future, hence the only way forward for me was to work quickly on a MVP, and iterate fast.

I did spend some time building web applications with React, but with Vue, the new kid on the block making waves, I decided to go with Vue, to try out what it had to offer. Building with Vue was easy and quick, and it was extremely easy to stitch components together, in a clean and organised manner. Soon, I was churning out components after components, and it was easy to get everything set up.

I really appreciated the containerised thinking of frameworks such as React and Vue a lot, how it could render components on the fly and the concept of a Single-Page Application made a ton of sense having got my hands dirty with these frameworks. Load times were faster, and it did feel like a very professional way to get things up and running. I really enjoyed the development process, and integrating UI frameworks such as Bootstrap and Material UI was no problem at all.

With development in full swing on the web application front, it was an extremely seamless process to get things up and running, making changes with the backend simultaneously to support new / updated functionality.

I was travelling Europe back then, and spent most of my time on Norwegian frantically working on the web application. It was an extremely motivational period, the thought of building something useful was an extremely exciting source of motivation which kept me going and going. I had my trusty Macbook Pro with me all the time — time spent waiting around is time I could’ve spent working on my application.

After about a month or so, I completed a rudimentary working version of the application, an unpolished alpha version which I was eager to let couples to try. I deployed the application on Amazon S3, and it was very swiftly in the hands of couples and friends, to perform the first test of idea and product validation.

It didn’t go as well as I hoped.

Couples liked the idea of the application, but many remarked that they would very much have preferred it to be a mobile application. A website made it inaccessible on the go, regardless of the fact that it was mobile responsive — there’s just something different about using an app and a website. Many suggested I look into building a mobile application, citing that it would be worthwhile to spend my time building it. The ability to pinch and zoom, drag and swipe across the screen was core functionality that made the experience of using an app different.

I was disappointed. Perhaps I had been living in my bubble for too long, blinded by the hope of building something useful that I glossed over the usability problems with the application. I considered the possibility of integrating touch and swipe within the web application, but it felt like a stop-gap measure to fix the problem, not avoid it altogether. At that point, a huge part of me wanted to give up on the project, and move on to build something new.

It was a fun ride, back to reality.

I rememeber sitting at Arlanda airport in Stockholm, wondering what my options were. I didn’t know how to build iOS applications then, so it never crossed my mind that I would even come close to firing up Xcode, but the thought of working on the web application which would serve little purpose no longer gave me the motivation it used to. I remember checking the flight times of my flight to the Czech Republic — two hours. That’s an awful lot of time to spend sleeping, so I decided to do the next best thing. I downloaded Xcode and a few tutorials on Swift, everything I could find to get started with iOS development.

Let’s give it a shot.

I remember spending the entire plane ride figuring out the syntax of Swift, how iOS applications work and how to get started. Thanks to free in-flight Wifi on Norwegian, I was ‘harassing’ a friend of mine on the inner workings of an iOS application. When I landed in the Czech Republic, I found myself in a nice cafe near Charles Bridge, and started to hammer away to build a “Hello World” application in Swift. It took a while, but I managed to fumble my way with ViewControllers and Storyboards.

Then I started to learn about basic styling, StackView, CollectionView, TableView, and suddenly the prospect of building an iOS application (while still incredibly daunting) became less frightening. Maybe, I could work on building kick-ass functionality, while learning a new skill.

I’d always been afraid of taking this leap into mobile application development, but now that my feet are finally wet, maybe it’s time to give it a go.

And that marked the start of my abandonment of a web application for my personal project, and a shift in focus towards an iOS application.

What about the Web Application?

Perhaps I’ll revisit it one day, when I’ve successfully managed to build a useful and working iOS application. There was little value to continue hammering away at a web application that no one would use, and where there was little for me to learn. In learning the mobile application development paradigm, I add to my capabilities as a Software Engineer, and also potentially build something useful for someone to use.

I hope to still revisit this someday, to build a better and more useful web application to complement the functionality of the iOS application.

I needed to remind myself that the topmost priority for building this personal project was my own learning: to be a better Software Engineer. Taking a step away from the Web Application was a right step — moving into unchartered territory, learning something new, that will go a long way in helping me get there.

In the next post, I’ll share more about the arduous process of learning how to write my first iOS application, and how the ‘pain and suffering’ has made me understand first hand a lot of the inner workings about mobile applications, and software engineering teams in general.