Category: Development

At the start of the year, I had an accident, the result, a rotator cuff injury that is slowly healing. I still have a long way to go before my shoulder is back to normal strength and mobility.

A shoulder injury doesn’t sit well with programming, my productivity for the first three weeks after my injury dropped to zero. I’m back at work; however, I am not yet at 100%, I’m working in bursts.

I initially planned to release the private alpha of the Costs to Expect App in November. Minor delays meant I pushed it back to December. Due to injury and typically development delays, I released the alpha yesterday.

Delays and setbacks with development are common. I use Pivotal Tracker; after years of use, my iterations are typically spot-on. In my case an iteration is two weeks long, it might contain 60 points worth of work, I’ll create ‘n’ new tickets and ‘m’ bugs. By the end of the iteration, I’ve mostly completed everything I had planned.

There are weeks when I work less, and I’ll adjust the team strength value to take into account absence, but when you don’t work for three weeks, the impact is enormous. It would be easy to think I’m three weeks behind, that isn’t true, I didn’t do three weeks of development however in that period I would typically create ‘n’ new tickets and ‘m’ bugs.

I can never recover the lost time, that is gone, I’m going to use this as an opportunity to review the ‘plan’ and re-prioritise. As good as the ‘plan’ is I’m reasonably confident there are some ‘likes’ I can move further down the list and ‘needs’ that can move up the list.

The Costs to Expect App is not an Open Source product; we intend to create a viable service; for now, we are keeping our secret sauce secret.

The App is built upon the Costs to Expect API, the API is Open Source and technically, anything we can do with the API, you can too. We aren’t gatekeeping your data; you can access your data through our App with the UI/UX we are creating, or, you can use other tools to fetch the data directly from the API.

To this end, we expose all GET, HEAD and OPTIONS requests, we hide POST, PUT, and PATCH requests as you can’t review them after the fact without unnecessary data being cached.

At the bottom of every page within the App, there is a table showing the required API requests. The table shows the request URI, the request METHOD, the response time, as well as was the request asynchronous or did we fetch it from our cache.

I appreciate that to the majority of users this data is redundant, yes there will be a visibility toggle; however, for the minority of users that are interested, I think the extra effort will be appreciated.