In May 2019, I was sat filling in a timesheet on Tempo, wondering yet again if I’d actually done the correct number of hours. Surevine allow flexible working, where you don’t have fixed working patterns or need to stick to a fixed number of hours per day. Just so long as it remains compatible with your team. 

The problem with Tempo

We use Jira with the Tempo plugin for time recording. With an internal project to capture holiday, internal meetings and HR things, data on 100% of the day can be collected. It’s great at that. It’s pretty great at reporting too… if you’re in a governance role and need to know project profitability. Tempo cannot easily solve my problem. You can do it per “period”, but we don’t care so much about that in terms of teams and individuals. If you work late on the 31st, you can finish early on the 1st – this is fine. What I really wanted to know was “How many hours above or below have I worked since Jan 1st this year?”.

Of course, I’m an engineer. The greatest thing about code – the thing I try to inspire my kids with – is that when a tool doesn’t exist, you can just make it yourself!

The solution – TempoFlex!

TempoFlex was born as a command line application. After a day or so of tinkering, authenticating securely when the credentials are stored in LastPass became unwieldy. It was suggested that I solve this by looking to port the logic to a Chrome Extension. This would make authentication a non-issue as it lives in the browser. By the start of June, TempoFlex was working and published to GitHub.

At this point, it became a background project that I used to learn. My strengths lie strongly in testing rather than developing applications. Particularly where testing is most exercised often against applications already built. I had an application available with one single stakeholder with whom I had permanent access to, and took the opportunity to expand my knowledge of implementing unit tests and what makes code easy & hard to test. Another blog post can talk as to why this is a bad idea in practice. However, as a learning exercise I sought and reached 100% test coverage. Initially attempted as an exercise in unit testing, that reached into rewiring of private vs public methods. It was then reworked as integration tests. Finally, test fixtures were rewritten for readability and to reduce repetition. All highly rewarding.

Over the course of this journey, I’d enlisted the help of others at Surevine to test changes and assist in solving some of the more intractable problems. In doing so, it garnered users and in doing so, accidentally accrued stakeholders with their own individual use-cases. What happens when someone logs tomorrow’s holiday today? What happens for users who joined the company this calendar year? The issue tracker accrued issues and those issues were resolved. This led to new additional features, such as SAST and dependency scanning, Firefox support.

Ongoing learning

Atlassian’s recent announcements about the imminent demise of Jira Server in its current license model could, in time, spell an end to the usefulness of TempoFlex for me, or conversely create a new set of requirements for TempoFlex for an entirely differently platform. Regardless of the future of TempoFlex, I look forward to picking up other projects in the future, and continuing to develop them in the open.