Building A Web App Part 1: Failing Fast
I‘m willing to admit that this series of posts is going to be a little off topic, however I’ve had enough engineers ask me about the wonderful world of web apps and how to build one that I thought it’d be worth doing a mini-series stalking me as I attempt to design one for, what will turn out to be, an engineering cause.
Unlike my Python guide, this will focus more on the process of getting something together. There’s quite a lot to cover (five posts worth, in fact), and I’ll only be able to give a glancing blow to some of the more detailed topics. I also won’t be stopping to explain the syntax, methods, etc. of the code I’ll be providing. I’m not saying this to put you off, quite the opposite. I recommend you go straight through this mini-series not worrying to much if you don’t completely get something immediately. Then go back and use the links I’ve provided fill in the details, once you’ve got the shape of the solution. I’ll also be providing the complete working code at the end of the series for you to pull apart.
You’re not going to be a web developer at the end of this, but hopefully you’ll know where to start looking.
So lets get started:
Nearly a month ago now, someone from the BIM2050 crew go in touch with me to talk about an idea they had for a website. We had a conversation and there was a lot of predefined ideas, context, and ‘like x meets y’. So I said “sure, I’ve got so much spare time these days that I hardly know what to do with myself- I’d love to spend it programming for you.” And that’s how I got where I am now.
I think one of the most important things to do when trying out a new idea is to set yourself up for failure. The chances of you just immediately coming up with exactly the right solution is zero to none, so it’s best to take an approach that means that you can fail at a low cost. I’ll probably do a whole post about how this philosophy can be applied to engineering, but for now that means that I need to distill all the hopes and dreams of the original request into a simple idea to be tested- a minimum viable product.
In this case, the idea can be summed up as:
A way of connecting people working in the built environment based on their interests.
That’s right. We’re writing Grindr for Engineers (that’s so very untrue, but it’s going to be a fun way to think of it). Although this idea is pretty simple, it’s actually a bit broad in its application. So to focus in on our minimum viable product we’re going to accept some constraints (because, as any mathematician will tell you; constraint maketh the solution). Our constraints come from looking at the most critical points in the original context:
- People will be connected by joining Slack channels that match their interests
- The target audience is busy; there should be as little friction as possible in the process
With these constraints, it’s possible to begin to shape a minimum viable solution- so we’ll stop there.
The Bare Minimum
Until now, I haven’t actually stated that this will be a web application (the original pitch was for one, but that doesn’t mean it’s right). However web applications are fantastic for minimising friction; all you need is a device with a web connection and a browser– no installing software, no traveling to specific locations, very little wait time. And thus, we now know that we’re designing a website.
The most useful constraint of the two is that people will be ‘connected’ by being invited to join a Slack Channel. That means that our minimum viable product doesn’t need to cope with maintaining the connection; just on establishing it. Or to put it another way, it only needs to identify which Slack channels you should join based on your interests.
So here we go:
Ask users about their interests and suggest channel names accordingly.
I know this doesn’t sound that exciting, but it does two things. It provides us with something that can be delivered very quickly but can still be used to achieve the principle aim; something that can be tested against to discover if the idea is good. It also provides a point for discoverability; something to build upon. We’re at the rapid prototyping stage here- it’s all about keeping change easy and failure cheap, and that means not investing too much in any given solution.
And that’s the first part- note the complete lack of code. This is because the absolutely fastest way to fail is to fail without doing any work at all. A thought experiment, a few sketches, just bouncing ideas around- these are all examples of failing fast. However, sooner or later I’m going to have to do some work; and that’s for part two…