Why
When I worked as a Software Architect in the Solutions department at Bushel, one of the things I had to do was track billable time for customer engagements. They used a nifty tool called Harvest for the entire department.
I picked this tool up for my own contracting/consulting engagements.
Unfortunately, Harvest was bought out and recently made some massive price increases, and the community reaction made it clear I was not the only one looking for a way out. There were long-time users saying goodbye, coverage outside the usual software circles, and plenty of people asking why they would stay.
I settled on giving a new solution called Tempough a chance. However, I still needed to replace the functionality I used to tie Azure DevOps issues to time-tracking entries in the billing solution: the Harvest Time Tracking for Azure DevOps extension.
What
Tempough Time is an Azure DevOps extension that adds time tracking to work items. It creates a Tempough time entry from the work item, carrying the issue reference along with it so the time stays connected to the work that prompted it.
It’s a simple widget that talks to the Tempough API through the Azure DevOps frontend (100% browser-side).
Vibe Coded
Since I needed something done quickly this time around, I leaned into vibe coding. There was minimal interest on my end on learning the deeper inner-workings of Azure DevOps extension management toolchain, etc.
Defensive Mechanisms
I worked out my usual framework of expectations with the LLM. Here are some key things I hawked on the agent to stay true to some rules I was most interested in preserving for easier maintenance:
Repeatable, local results: Everything that needs to be done iteratively, e.g.: local development, packaging for AzDo marketplace, etc. has to be wrapped in a makefile target. I do this approach so it’s easy to quickly get back into the development of a codebase I’m unlikely to frequent and keep fresh on mind.
Rigid architectural rules: To make it easier to deal with future friction created from future changes on either the AzDo side or the Tempough side, I enforced a quasi-ports-and-adapters approach.
What Matters (and Does Not)
Personally, I’m ok leaning super heavy into the vibe coded aspect of this. It doesn’t mean I’m completely clueless what’s going on under the hood. Certainly there are areas that I don’t know, specifically the React specifics for Azure Devops widget rendering and the marketplace packager. Totally good with that decision because I’m not interested in the narrow, niche knowledge of that stuff.
What did matter to me is keeping it maintainable, and to have it in a state where I can claim accountability for what’s going on inside. In fact, my fingerprints are very much so all over the organization, versioning (to deal with marketplace idioms) and locally repeatable results.
Special Thanks
Special thanks to ‘Tim’ of Tempough for being so responsive! Tempough is a new product, and this integration would have been sunk if they didn’t make a CORS rule adjustment for AzDo. Other minor fixes for API docs were also made super quickly.
What’s Next?
Well, I still want to plunk some time into scaratching the Cron* expression itch in my previous post.