HANDY — The best Hands for your Job
As a part of our Web development Immersive Boot-camp at General Assembly, Singapore, we — Yi Sheng Lee, Ng Zhao Loong, Andrew Thian and I, Sharona — had to build a full stack website using Ruby on Rails. This post is the result of our reflections on some of the things that went well and also some of the things that could have gone better.
The project was conceived as a platform that brings the tech savvy common man closer to handy men around the country without the means to reach the end customer. Through our website, the handy men can register themselves as freelancers/handy men along with the schedule of dates when they will be available for booking. The user, with requirements, can then search through the profiles of the registered handymen and send an inquiry with the desired price and date. The user and the chosen freelancer can then engage in further negotiations with the freelancer through the in-built chat box and finalize on a mutually agreeable time and cost.
At the outset, we decided on the features that we wanted the project to have, like — booking capability, chat box, location features, search capability and rating system. Because we had a very limited time of one week to submit a working product, we decided the best way to go about the implementation was to have each of us build a separate feature and then work on merging. The best work flow for this would be the git-flow work flow. So we had a master branch and a separate development branch. We would initially push to the master branch and resolve conflicts and only after we had ensured the proper working of the website would we push to the development branch.
The project was a huge learning experience for all of us, since it was the first time we were working in a team for a project. We could implement most of what we wanted to, albeit with its own difficulties. The integration of all of the features also worked quite well minimal conflicts in code.
However, we were so engrossed in building the functionality that we never really thought much about the front end and UI/UX designs. In the end we were left with very little time to do the styling and UX design.
We knew right from the beginning that the consolidation of each of our features was going to be a challenge. Each of the features we were working on were so far apart from each other that integrating them was definitely a huge challenge. Since we anticipated this early on, we were able to overcome the same by good planning. Since we used the git flow workflow, we first pulled each other’s branches and solved conflicts and got the code working before merging with the development branch. This saved us a lot of time and effort in terms of bringing our website together.
Working in a team was overall a very good experience. Since we had a very short time to come up with a working product, working as a team definitely helped in rolling out a lot more features than each of us could have done individually. However, we each agreed that the overall feeling of ownership for the website was absent since there were still some features on the product that each of us don’t fully understand.
Our team could really gel well together. We were each quite open to each other’s ides and the end result is a product of all our ideas combined rather than it being a brain child of just one dominant member of the team. The communication and synergy in the team was really good and this helped in coming up with such extensive features within a period of just 5 days. Each of us were also very committed and dedicated to making the features work.
This was also a huge drawback, since we were so engrossed that we couldn’t focus on anything else at the given point. This also caused some delays in the deployment of the project
If we could start the project over, we probably would do it the same way. From our previous experience with the other 2 projects we realise that every project goes through the same curve of initial optimism and then the endless head-banging and sleepless nights till the last minute before finally coming up with a working product. But if we could change anything we probably would want to plan out the timelines better and come up with a working product earlier in the week and then add on additional features.