Thursday 3rd May, 2012
Our new-found focus on, well, focusing, continued in Week 172, but we have very temporarily parked Sauron in order to get Recap to 1.0.0. We’ll explain more about Recap in another blog post today, as soon as Tom emerges from his documentation fugue state, but if you can’t wait then feel free to check out the code in the meantime.
During moments of respite from chasing the chaotic agencies required to arrange a mortgage, James M has been doing more sterling work on Mocha, solving the issues that people encounter when they try to do crazy stuff with stubs and mocks.
This week someone has been attempting to serialise a stub within an ActiveRecord object. James has a quick fix, but there’s more thinking to be done about whether or not Mocha should actually prevent you from trying to serialise stubs in the first place.
What does GFR do?
Chris and I took a step back from Recap on Thursday morning to roughly map out what GFR has done. Like, ever. We roughly categorised the fruit of our labours into five categories: products, apps, libraries, client work, and philosophy.
We weren’t entirely sure that this would be interesting while we were actually doing it, but looking afterwards has definitely given us a sense of what things – like the mechanics we use to run the company – we might polish and make more available to the world.
I also dropped of another couple of printers for James Weiner and Russell Davies on Friday. Exciting times in Printerland; I’m hoping we will learn a lot from them about what aspects of the overall system are confusing or unintuitive.
Businessing & RFPs
We’re lucky enough to have a reasonably steady stream of interest from potential clients, and we make a conscious effort to try and speak to everyone at least once. Even if it’s unlikely that we’ll actually develop software for someone, we hope that at the very least we can help them think through the problem they are trying to solve.
One potential client approached us this week to ask if we’d be interested in participating in an RFP (that’s ‘request for proposals’) process.
We are suspicious of RFPs, because they tend to involve a lot of up-front design and decision-making.
We are really uncomfortable with the idea of selling clients on any vision of a ‘finished’ solution. We know that it’s more effective to explore problems by building working software, since doing so will often lead us in a direction different to the one we imagined at the outset.
When a client engages our services, they aren’t buying the guarantee of some finished product at some point in the future; they are buying our skills and expertise to get to the root of the problems the are trying to solve, and explore how we can use software to address to those problems.
Now that the European Space Agency has committed to sending probes to the moons of Jupiter, we’ve ramped up our Space Research Division to get ready for our pitch to build the probes themselves.
Obviously our software ethos would guide our approach to building the probes; we’re going to recommend that rather than spending millions of Euros upfront on planning and design, we start launching probes as soon as possible, and then use feedback from each one to iterate towards the ideal probe. It takes about six years to get to Jupiter, so once we can retrieve the probe, and obviously building in time for a retrospective, we’re looking at a 12-year iteration length. Seems fine to us.
(Our other idea was to build a probe that was capable of iterating itself via some onboard system of self-programming and 3D printing, but we decided that the chances of it returning as a malevolent artificial intelligence were too great to risk it.)
I’m hoping that we’ll continue pre-emptively answering the question what should I be doing today?, but as yet we haven’t decided what that will be. Will it be more Sauron? Perhaps some work on Printer? Who knows!
The only way to find out will be watch out for issue 173 of the GFR weeknotes!
– James A