Posts tagged as bredon

Week 126

A good week, setting up exciting foundations for Week 127. For starters: a couple of days on Bredon, a workshop with Max and the team at After The Flood. It’s always a pleasure to work with Max, and this was no exception: two intense days of good chat and brainfood.

There were also a bunch of meetings – a few exploratory ones, and one setting up a project called Selworthy that would need a pitch writing next week.

Week 127

Week 127 saw the beginning of Selworthy: a fairly intense full-stack web project with a really interesting problem to solve.

I spent Monday formalising a pitch, whilst also derisking the project. That meant writing small bits of code to explore particular issues – parsing particular formats, understanding Amazon S3’s security model, testing character encoding issues. I also researched my proposed architecture for the project a little.

I always find it hard to balance the right amount of research and derisking: too much, and you end up starting to build the project; too little, and it impacts estimates and planning. In the end, I think I err on the side of too much, knowing that with any luck it’ll be re-usable in the course of the project.

The client was happy with the proposal on Tuesday, so off we went. It turned out that the early derisking had paid off and in the rest of the week – including a Friday on-site – I managed to achieve most of the first milestone of the project.

I’ve broken the project into three milestones. The required functionality won’t be complete until the end of milestone 3 – although milestone 2 could feasibly be described as a minimum viable product. At the same time, breaking the work down this way has been helpful for sharing my understanding with the client and getting their input. It’s also a way to keep risk contained – each milestone builds on the previous one and confirms that the next one is possible.

That also assists estimates. Like almost all developers, I find estimating hard, and I also find that the easiest way to make an estimate more accurate is to do the work. To that end, each piece of work helps estimate the next one.

Milestone 1 is basically a prototype; it tests all the core functionality and sets up the architecture of the code, as well as getting the production infrastructure good to go. By the end of the week, it was clear that my conservative estimates were reasonable, and we might well have some time spare. Rather than saying right now ‘it’ll be cheaper‘, I’m clarifying that it’s all time-in-hand within our current budget and it gives us room to breathe if future code turns out more complex.

Anyhow: it’s going well so far, and it’s exciting to work on something that’s challenging in all the good ways. The next few weeks are going to be head down on Selworthy, and that’s going to be good.

(Oh, and I almost forgot: on Tuesday, I finished the script record for Periton. So that’s all in the can, from my end.)