This post comes from a series; read the series overview here.
It’s hard to remember every decision you make as you begin a project, especially if you’re not quite sure you’re beginning one (see the intro linked above). But as with setting out on any journey, it’s best to bring some preparations, possibly some snacks.
If the project happens to be one involving computers, you have a lot of such preparations you could make. What programming language do we use? How is data stored? How do I get the software to the user? You won’t have an answer for every single one of these - and even those you do have can be hard to guarantee as the right answer but regardless what you choose, it’s important to remember that it does matter.
The startup world has changed a lot since I entered it 10+ years ago, but a lot of core methodologies persist. One of these is the Lean Startup, popularised by Eric Ries’ 2008 book of the same name. The book has a lot of great content so I am by no means disparaging it, but it’s always worth realising that not every concept applies to every business, and your mileage may vary. There’s also perhaps a more common misuse of this book (and in fact many popular startup books or techniques) which is to take the headlines without the context.
For example, the concept of Minimum Viable Product (MVP). This is a great idea at its heart - build the minimum you need, and then get it shipped to customers. Rather than 3 years building every possible feature, ship a core feature, get feedback, iterate.
But hold on just one moment. That middle word “viable” is doing a lot of work here, but it’s tempting to look at the other two - “product” (yay I’m building something) and “minimum” (yay less work). Viable in this case should extend beyond just “it works” - what you build now may need to work forever.
Rapid prototyping is a thing in software. Or even just regular old prototyping. It’s a perfectly sensible thing too - build a prototype to test that the idea you have is valid. In the case of Ground Control (to try and avoid being too abstract) the first big concept was a drag and drop interface. Skydiving is quite a logistical exercise - there can be multiple planes, possibly travelling to different altitudes, different categories of jumper, people using rented parachutes that need to be packed by a staff member, instructors (sometimes two of them) for student jumpers… it can get complex.
One of the first centres I visited was using a big table, pieces of paper and actual model fuel trucks to plan refuels (a nice touch). At the time most software in the industry was built like a spreadsheet (a lot of it was just VBA on top of Excel or Access) meaning a lot of clicking to move things around. This meant that compared to a big war desk of paper the computer systems actually felt slower, despite the longer term benefits of data consistency, reporting etc that they could provide.
By pitching Ground Control in a web browser I could take advantage of a lot of nicer features than regular desktop software, and in 2010 it was still somewhat innovative to put software in a browser - for a number of years a common question was still about rebuilding the system as an on-prem version. So with a browser based system, the first killer feature was a drag and drop interface, which I was able to prototype in short order with jQuery UI and some truly horrendous gradient colours and box shadows.
At this point the key process to follow would look like this:
- Let the first customers see a preview
- Get feedback on the interaction
- Sit down and consider how this is built into a wider system
But of course it went something like this:
- Get excited at having built something cool
- Spend two weeks adding more features
- Chuck some screenshots at the customer
- Spend another four weeks adding features
- Tell the first customer they can go live using it
Nearly a decade on, jQuery UI and a PHP framework of my own accidental creation still sit at the heart of Ground Control. More modern practices have sprung up around parts of the codebase - better separation of concerns, safer SQL queries, things that really couldn’t be avoided. But the core is the core and ripping out the interface layer to replace it with React (or any other JS framework over the years) isn’t feasible when most of the back end ships little blocks of HTML to the front end. Similarly replacing the back end with a framework becomes a huge undertaking with 100+ different possible interactions.
All this goes to show that early decisions do matter, and I’m far from the first developer to build a prototype and find it running in production years later. Had Ground Control grown into a larger business at some point we’d have had to bite the bullet and rebuild both sides (likely separated, and after adding a good range of contract tests) to avoid the pull of technical inertia.
So whilst you’re working on that minimum product, consider just how viable the choices you’re making might be for its future.