In February 2016, we were asked to create a time tracking tool as requirement of the university course "Software Development and Project Management". There were some requirements:

  • Ability to stamp in and stamp out
  • Ability to add holidays and absences
  • Including Collective agreement arrangements
  • User management
  • Admin-Interface with Statistics, accepting and declining holidays and so on

We were specifically asked to use the Play! Framework as a backend. We could have used its built-in frontend framework for the user interface, but we took the opportunity to get to knowa new web framework, called Angular2 (now called Angular). We used Angular2 instead of AngularJS (which was the stable version at this time), because Google (maintainer of Angular) changed nearly everything from version 1.x to version 2.x, so we thought it wouldn't be quite intelligent to base our software on the old release. So we built our Frontend with a completely new framework, which was in Alpha Stage, which turned out to be a bad idea in the end.

But back to the software we developed: I want to go deeper into the architecture of the project and the "missing" time management we had, because I think that was one of the key things we learnt.


Our backend was a REST - API with all the logic behind. Our frontend interacted with the API and visualized everything. We did because we thought it would be cool to have an API, because we would then have the ability to easily write an app for it.

The clean separation also proved useful because we could implement something in the UI which wasn't finished yet in the backend. But here's where we made mistakes: We didn't specifiy the API endpoints in detail, so front-end developers prepared code for endpoints that back-end developers hadn't even considered to code. That was an unnnecessary waste of time.

But what we were really missing, which would have solved the specification problem and many others? Writing tests. Writing tests is really painful, no one really likes it. But if you have time to do it? Do it. It solves so many problems, it's awesome.

Time Management

One big problem of our project progress was that we kind of underestimated the project. We began with very few hours a week and ended up working about 50 hours a week to finish it on time.


As you can see, the time we invested in our project was growing every week. If we would have started early it wouldn't have been such a marathon in the end. This was another thing we learned from this project.


All in all Times was a really cool project, we had a lot of fun and learnt a lot for future projects. I think developing projects is much better than reading books or trying out specific things, because you get better in every way, with every line of code, with every mistake you make, and you learn to handle pressure.

Here are some screenshots of the product we handed in. In the end, we won the IT-Award of the city of Innsbruck with it.