-
Notifications
You must be signed in to change notification settings - Fork 2
Assessment
We, as the Kereviz team, feel like we succeeded in creating a cross-paltform, decentralized language learning platform. We were constantly in touch with our customer, being aware of their requirements, we accomplished in satisfying most of them.
We met weekly and talked with our customer, decided what to work on, divided the work and planned our process. We tried to adopt an agile philosophy since many of us were incredibly inexperienced and planning without estimations and predictions were a nightmare, so we took it a step at a time. Every team decided on the roadmap of its own, we were lucky for our back-end team was running a couple steps in front of us so our android and web team could work without limitations. Our android and web team took the approach of "who implemented the feature the first time, decides the design. The other will comply.". It worked well since we do not have a designated designer.
We were pained to realize that some of our teammates were not putting in the same effort, which resulted in the trade-off of implementing less features, implementing them in a lower quality or putting many extra hours to comply with our contract with our customer. We felt bad every time we were faced with this decision, and every choice was the way to go more than once.
All in all, it was an invaluable learning experience in multiple domains. Each of us worked in a cross-platform application with many moving parts in it. We learned to work in a team, and working with people is hard. We learned how to interact with a customer and how to understand what to make of what they want from what they say, which can be surprisingly different. We implemented a W3C standard, which was in itself a serious achievement. We deployed and managed a server by ourselves, we implemented a continuous integration solution for testing and fast deployments. We had good moments, we had bad moments, and we learned how to handle them all. Sometimes we rallied, sometimes we compromised to find a good balance with our customer. We motivated each other, not a single serious conflict was present since we were all extremely constructive with our criticisms and suggestions. Thank you for this growth opportunity.
When we started this project, we as the Android team didn't know much about Android programming. We started out with tutorials and tried to develop an app from scratch.
At the end of the project, we have most of our app working in the way that we wanted. We believe that we have improved greatly.
For example, when we first started programming we had system.out.printlns as our debugging method. Then we improved to using Android logs. Then we discovered Android Studio's debugging tool.
We believe we improved on using the GitHub tools as well. We now write longer issue descriptions, pull request and commit messages. We also started using projects to keep track of the issues.
One of the points that we could improve as the Android team is the state of directories of our codebase. We don't have any directory management system under Android code, we simply put every java file to the same location. We are aware of this problem but as we had limited time to implement new features, we couldn't find time to organize our directory.
Another point that we can improve is the testing of the Android app. As our app is highly dependent on the backed for logical functionalities, we don't have any unit tests. We would like to write more tests but we didn't know how to or what to write tests to.
We, being the awesome front-end team, aspired to write the best web application we can with the resources we currently have. Working side by side with each other, we succeeded to reduce the differences of our experience levels greatly. With the back-end team implementing the functionalities of our application, we attacked the issue of interacting with our users.
Our github usage was satisfactory, we used branches for feature development and issues for figuring out who is working on what at any moment. We used pull requests for code reviews.
Our work hours were bursty, as in implementing many features at one sitting, our schedules are nearly full and working in the same place at the same time appealed to us. We rushed to develop our application generally near deadlines, and sometimes our product quality suffered for it.
Implementing the Annotation model was hard, and doing it in the front end was a necessary evil if we wanted to have that feature in our product, and Halit was the one who stepped up to that challenge, just sending and receiving strings from the backend. It was hard work, and he pulled it off. A better choice would be the logic being on the back-end part, but that team had their hands full and android team had decided to not implement it so this decision was our only choice.
For the less experienced developers on our team, the hard part was learning, taming and integrating some less-than-optimal, not-so-cleanly implemented libraries into our code base. Sometimes it took delving into the source code, sometimes it required some cheating and abusing its exposed API. Without the help we gave to each other, it wouldn't be possible. Strong teamwork paid off.