Tools – FilemakerPro

At a time when new web-based tools that help with one aspect or another of the development cycle pop up every other week, and when the number of free development environments is so large that choosing between them might be seen as a job in itself, it might seem odd to be promoting a database aimed at non-technical users as a prototyping environment – especially when it will be 20 years old next birthday. Factor in the cost – at around £280, it’s easily 100 times the cost of a typical app – and you might be wondering about my sanity.

But as I kicked around the options for getting a working MVP of our health/fitness app to the point where I can show potential users and investors something that actually works, and which will communicate the value of what we have imagined through hands-on use rather than verbiage, I was finding it hard to stay positive.

The options seemed to boil down to two:

EITHER:
– knuckle down and learn enough coding to build something myself.
OR:
– grub up enough cash to get something done by a freelance / small software house.

Let’s take those in turn.

Roll your Own

This is the recommended route, as I understand it – I’ve read several fairly no-nonsense blog posts from people who certainly know a great deal more about developing software than I do (here’s one, by David Gewirtz, who somehow manages to be endearing despite his self-boosterism, outsize ego and boasts of links to the US security apparatus). The message is pretty blunt, and he sums it up thus:

Here’s a simple piece of advice: if you can’t write your app yourself, typing it on your own computer, doing the work yourself, with your own brains and skills, don’t do it.

I understand this completely. You may have a great idea, but without nitty-gritty domain-specific knowledge, it is unlikely that you will be able usefully to imagine the detailed implications of a real implementation of that idea. At best, your solution will be inefficient, and it will quite likely be fatally flawed, so that it can never do its job properly.

In my own domain, it is easy to tell when architects who have never made anything with their hands have designed pieces of furniture; their ignorance of the language of timber, of how joints work, of fixings, of finishes results in flawed, awkward pieces. Ignorance of what it really takes to have a chair have integrity makes it very hard to design a decent chair.

And the condition of software is much more problematic than that of furniture design – the range of possibilities, the mutability of the tools and the material, the pace of change – all are orders of magnitude larger in software.

Thus I was fairly easily convinced that this was good advice – despite the lurking suspicion that experts in all fields, no matter how well-intentioned, are prone to be of the opinion that only experts can produce anything worthwhile (if us punks had listened to that advice in the late ’70s we’d never have had half the music that sustained me through the ’80s. However, I’m convinced that Marshall McLuhan‘s insight is accurate; different media do indeed have different structural characteristics, and these strongly condition the viable modes of operation in each; pop music is a ‘hotter’ medium than software – it just is).

Good advice perhaps, but practical – not so much. Now, I’m not completely ignorant about coding – I even worked as a computer operator/coder for a year in my youth, and earlier this year I did an excellent on-line course which taught me how to write simple Android apps in java. I understand what html is, what css is, what a database is, and can can write simple sql code. Perhaps more to the point, I am confident of my ability to jump into something and, with the help of some manuals and a search engine (no, Google is NOT my friend, or yours either – try Epic browser or StartPage instead), to get somewhere – eventually.

And that’s the problem. Let’s go back to furniture again; back in the early ’90s, I was designing and making all sorts of furniture in a fantastic workspace run by Dan Monck,  the prototype for what has become the amazing 115 co-operative building. With an entirely academic/intellectual/impractical parental heritage, I was teaching myself how to work materials from scratch, to make my own designs real. I am proud of what I achieved, but one day I was trying to get my chisel really, really sharp, following the advice in all the books (using a really flat stone, carefully keeping the chisel at the exact angle, and so on). I spent ages on it, and at the end I wasn’t sure I had even improved things. I stopped for a break, watching another guy in the workshop, a time-served pattern maker who had spent years making timber originals for metal-casting moulds to amazing accuracy; his sharpening stone was absolutely not flat – it was curved in all directions like a saddle – and he seemed absent-mindedly to flash the chisel around in a decidedly curvy way for twenty seconds or so, after which it was razor sharp. At that moment I realised that, whatever I could bring to the exercise in the way of good ideas, ingenuity and old-fashioned stick-to-it-iveness, I was never going to be even half as fast or accurate as he was.

No matter how much I accept the suggestion that making it yourself is the way to go, the reality is that we need a working MVP implementation in a couple of months – much longer, and it will cease to be a believable proposition. I am not going to code it myself.

And so to the second option:

Contract it out

If DIY is impractical, then you have to get someone else to do it. Simple as that. My heart sank. That startup software development needs to be an iterative process is now axiomatic (in fact, some of the thinking behind the development of the Agile Manifesto seems likely to have been inspired by my architecture teacher, Chris. Alexander, who included a pattern called ‘Gradual Stiffening‘ in his 1977 masterwork ‘A Pattern Language‘, since four of the original Manifesto authors were early promoters of the pattern approach to software design inspired by the same book).

If we could sit down at this stage and write a specification for our app that was sufficiently definitive and which we could be certain would be viable that would either be because it was pointlessly trivial or because we were copying something that already existed.

But all the advice on hiring freelancers/software houses is that you need a definitive specification.

Again, from my experience in the world of construction, this makes perfect sense. It is only the relatively limited and well-understood menu of possibilities, materials, methods and uses that makes writing a definitive description of a proposed building viable, and the process is still notoriously unreliable (construction contracts are very carefully written to allow for change as you go along for this very reason).

So I was looking at two unattractive options; either raising a substantial chunk of money to end up with a result that would at best be an intermediate solution, or burying myself in manuals and StackOverflow for a year, to end up perhaps with a more refined product, but with every likelihood of running out of self-belief (or some other vital resource) half-way through, not to mention that the code would need to be completely re-written by someone who knew what they were doing immediately afterward.

Enter Filemaker

I have used Filemaker extensively in the past, making in-house workflow support systems for architects, for kitchen companies, and for a community LETS scheme – but I hadn’t built anything new with it for years, and all of these systems had worked over intranets. The most recent version I had used was the 2007 vintage, which was made for intranets but didn’t really address the web, let alone mobile devices.

Eventually, my conviction that the more obvious routes weren’t right for us made me look again, at which point I discovered that, out of the box, the basic version of  FPro 2013 will serve one web and one iOS client. Not only that, but the screen-building tools have had many features added that can approximate the sort of things we have come to expect from web interfaces (things like tooltips, popout windows, easy construction of list filters etc).

It is also highly tolerant of changing ideas, changing data structures, and it handles media well.

So I can proceed with the construction of a viable database structure, make reasonable web and mobile interfaces with relatively sophisticated functionality and deploy these to devices over the net. Best of all, I can do all of this without learning nitty-gritty coding, yet in confidence that the fundamental architecture of what I am producing will make sense to whomever eventually builds a hard-coded version. In fact, the working FPro system will make an excellent basis for a specification.

If we have any success at all, it will have to be re-written, as it seems likely that attempting to serve more than 50 concurrent users will become painfully slow (to serve more than one at a time, Filemaker Server is required, with additional concurrent licenses available in blocks of five). But that’s fine with me – long before that point, we’ll have proved to ourselves whether our idea is a runner or not.

If you, like me, have an idea for a digital service but don’t have the time to learn three or four distinct languages and the nature of the inter-relating services that implement them, then consider FilemakerPro as a development environment.