“iFlipd is a web application that allows you to rent books or textbooks on a weekly basis for as low as $2 per book, per week. But they aren’t just a Rent-All shop for students. iFlipd is also a library, campus bookstore and and a scholarship program. They want students to instantly have access to the books they need, when they need them. iFlipd also allows you to “flip” books back to the community, share study notes, and stay social — just like school. And you earn rewards for doing it!”
At the beginning
Since the application was built with old web technologies and the old way of implementing code or structure architecture (let’s say it’s a procedural way), we did a lots of code refactors, tweaks and manual fixes. These were for the responsiveness of the application user interface to be able to fit small devices.
When we added new features to it to extend the functionality of the existing modules, the application became more complex and lost maintainability. These issues might slow down the application’s performance. So the team asked to rebuild the application from scratch and to use new tools and framework. We also proposed a new development cycle for the application using the Agile methodology with Scrum.
Trial by fire through Ember
During the rebuild process, Ember looked to be a great solution for development. The team set a shorter timeframe for it because it seemed that the functionalities and other requirements for the application were already there in the old application.
As a beginner of the said framework, however, I felt lost in the world of Ember. I knew Ember and Ember-Data were very powerful. The documentation showed how easy it was to use. Unfortunately this wasn’t so for all scenarios of the application. Multiple times I was stuck because things didn’t go as I expected. Ember didn’t do things the way I thought it would. (This isn’t to make Ember look bad. It’s most probably my lack of experience with the framework that was making it difficult for me.) I considered this as a roadblock that might delay the delivery of things that needed to be done early due to our shorter timeframe.
I realized that I could be the reason for the delay of the rebuild, so I researched further about it, doubled my time in studying during weekends. Learning the so-called “Ember Way” and the internal designs of their structure architecture was a great help in understanding and implementing certain tasks. Ember is a little rough for beginners like me, but it is powerful. When I understood more about this framework, the team and I continued to develop and add more features to the application faster than before.
Enough talk about Ember, though, let’s continue. 🙂
We have had daily standup meetings with the client for updates. During our sprint planning, we’ve discussed specific criteria of the issue or tasks and estimated story points per tasks in our poker planning sessions. Through this technique, both the client and the dev team could now easily track, organize and manage the project’s concerns during the development process. We could also prioritize and discuss specific issues that needed to be done first including bug fixes and minor copy changes.
Our process improved team performance on delivering tasks on the said deadline based on the story points set during poker planning sessions. The team also has an experienced Quality Analyst who tracks and reports bugs during the test process, which we can address immediately.
We’re continuing with the application’s development and enjoying the process, doing some minor bug fixes and adding more features to it. The application is now up and running and it continues to acquire more users, helping more students save money on books.