Reduced development time :(

As I have mentioned before, I’m lucky enough to be able to take time off during the year to work on my projects, every time I take on a new contract my schedule goes out of whack.

When I’m not contracting, outside of real life commitments, I try to dedicate as many as 30hrs per week to work on my projects, when I’m contracting that isn’t possible, a 40hr week with travel doesn’t leave much free time.

The last two weeks have been an adjustment, I managed to log 5.5hrs the first week and 7.5hrs the second week, I’m on track for 10hrs this week.

Is this a real problem, no, the first world called and wants a tissue, the issue is expectations, during my summer off I steamed through my work, with reality hitting, productivity takes a nosedive. Eventually, Pivotal Tracker will update to show more accurate completion times; once I’m three sprints in, until then, it is frustrating looking at completion dates that are optimistic.

Why am I blogging about this? As the site byline says, I was musing.

Releasing…works

I have a long-term project, Dlayer, that I very much believe in, but after many false starts, it still doesn’t exist, it will though, I’m due to restart it later this year with a slightly different focus 🙂

Why did I never finish or release the project? I never managed to hit what I considered to be the minimum viable product (MVP), my idea of the MVP for Dlayer was too vast, and far too much for one developer, I never managed to get enough done.

Early last year I needed to develop a small library, my PHP Quill renderer, I developed just what I needed at the time and quickly released it, within six months I bumped it to v1.00. I knocked it to v1.00 because I was confident in the library, it had warts, but people seemed to be using it, it wasn’t just solving my personal problem.

I’m not suggesting tagging it with a v1.00 release number made it slightly popular, I’m saying that because I was confident enough to add the v1.00 release number it became more popular.

Tagging the library with v1.00 meant I had to handle it differently, I needed to ensure the README and CHANGELOG were accurate, and up to date, tests are required, and I needed to learn how to handle the pull requests I started receiving. All of this made the library better, as I’ve said in the past, nothing makes your code better than knowing there is a minuscule chance other developers will look at your library.

During the summer I released two apps, both v1.00, the REST API for Costs to Expect and the companion Web app. Neither of these apps is complete. The REST API is missing quite a few features; however, it supports enough to get the job done, replace my spreadsheet and allow my wife to submit data.

I’m not saying anything new; there is a blog post by Jeff Atwood referencing a blog post by Chuck Jazdzewski stating our job is to ship. Knowing that is one thing, doing it is another, I wish I had had the confidence to ship earlier, and I hope I keep it up.