Category: Costs to Expect

Posted on

Slowly developing Costs to Expect

I’m developing Costs to Expect in a slightly different manner to any of my previous large personal projects. The process is slightly different for two reasons, firstly, the design, secondly, I’m deliberately developing at a slower, more iterative pace.

Design.

There are two parts to Costs to Expect, the Open Source API and the website, the website will include the secret sauce for the service.

The API has not been explicitly written for the Costs to Expect website; the intention has always been to use it for separate projects and idealy give back to the community, hence being Open Source. So far, I have one other project that uses the API, and I have plans for another rattling around my head. I’m confident that eventually, tomorrow maybe, I will add a feature to the API specifically for the website. I intend to try and ensure features are only added to the API if they make sense in the context of the API.

Slow, iterative development.

I released the API during the summer and developed a simple app to allow my wife to enter expenses for our children; the API is not anywhere near complete, I am continually fleshing out the features priotising the features I need to develop the website, the latest example is sorting. The web app my wife uses does not require sorting, the public Costs to Expect website does; that is why I’m adding it now.

There are three initial phases of the development of the website; once all three are complete, the real project begins.

Phase 1: The website consumes the API and shows the current expenses for our children in an engaging way for public consumption.
Phase 2: My Wife is able to transition from using the web app I developed in the summer; she should be able to do the expenses management for our children using the website.
Phase 3: I develop the forecasting and budgeting systems and start opening up the website to a restricted number of test users.

I’m very much in Phase 1. I envision I have at least another four weeks of development before I can progress to Phase 2.

Phase 2 isn’t complicated; I need to ensure I make the correct decisions, I need to work out my authentication, probably oAuth, how I’m going to handle users, groups and then develop the management pages.

Phase 3 will be when the fun begins and the part I’m most looking forward to reaching. Phases 2 and 3 require time; I mostly know what is needed; I need to design and then code the systems.

The majority of my year off will be in Phase 3, I know what I need to end up with, however, I’m currently not quite sure how I’m going to get there.

For each Phase, I’m developing very slowly; the visual design is mostly solved thanks to a highly skilled designer I employed late last year, I mostly only need to think about what I need and how to develop it.

As a single developer with limited development time and resource, I can’t afford to waste any of my development time. I’m prototyping every feature and then slowly developing them, as an example, the website won’t be connecting to the API until at least v1.04.0, up until then I’ll be working on the responsive layout, building the view components I require and experimenting with the UX.

Posted on

Year off

Eight weeks ago I concluded my 16th contract, yes, I have been contracting for a while, over ten years so far.

I enjoy contracting; I continually meet new people; additionally, by moving around, I have been fortunate enough to be exposed to numerous business domains, frameworks and tools.

We can’t ignore the elephant in the room, contracting pays well, especially when you have over 20 years of experience.

In April, my Wife had our second child, Niall. When we had our first child, we realised that the best way to provide the support my Wife needed was to take time off, there were so many positives with me providing the support rather than getting in professional help. Well, with Niall, we are going to do the same thing, I’m going to take at least a year off, primarily to help my Wife raise our brand-new son, secondly, to try and get the Costs to Expect service off the ground.

Costs to Expect is a project I had been considering for a while, during the summer I released the first version of the API; I plan to develop the MVP of the service during my time off.

Twelve months is not as long as you think, especially when you are a single developer. I’ve used Pivotal Tracker for years; it has become scarily accurate at predicting what I will be able to accomplish during a two-week sprint. I usually have two or three sprints worth of work in my backlog, according to Pivotal, it is going to be quite difficult to get enough of the service ready in 12 months, hopefully, if I plan well, I should be able to do it.