7 Tips for Rapid Prototyping with Code
One type of software development practice that is rarely discussed in great detail is rapid prototyping. But having done it myself for over 10 years, and having watched other engineers do it, I’ve noticed that there’s a few key skills and traits that make some people more successful at it than others. The key ones being that they can rapidly come up with solutions, work around obstacles, and avoid getting hung up on issues that aren’t really important. I think rapid prototyping is a legitimate engineering discipline in itself, which is valuable for businesses to invest in, and one that engineers can master with practice, and (as it’s mostly about engineering mindset) mental training.
Modern web product development today is guided by a focus on validating new ideas as quickly as possible. Since software development is expensive and time consuming, product managers and UX designers use all sorts of tricks to validate their ideas without code today, from paper prototypes to high fidelity flows built in tools like Invision. But sometimes the only way to truly test an experience is with working code and real data.
Here’s my list of tips for any software developer who wants to master rapid prototyping:
1. First, You need to have a keen sense of what matters for your prototype. Does the code need to scale? No. Does it need to be optimized for performance? Not yet. Does it need to be secure? Maybe not. Should you be spending time on unit testing, obsessing over code style, or documentation? Also, no. All that matters is the experience you’re trying to create or the outcome that you’re trying to prove. After all, if the prototype fails, none of the time you spent on those things will have mattered.
2. When deciding on what technologies to use, the simple answer is to use what you know. If you’re trying to get an idea built in a few hours, now’s not the time to try out that new framework that might be cool to use. Whether you need a front-end UI, or backend database, use whatever solution gets you going the fastest.
3. Deal with problems fast. Inevitably you’ll hit obstacles, whether its bugs in your own code, or faults in 3rd party code. Now’s also not the time to spend a day debugging that C library that won’t compile on your machine. Regardless of what’s going wrong, your priority is to find a workaround as quickly as possible. Maybe you can hack up a quick alternative to that 3rd party library, or find a suitable replacement. Maybe you can get around a memory leak with a periodic restart of your app. Either way, fixing the guts of something that’s peripherally related to what you’re prototyping is not your priority now.
4. Aggressively avoid premature optimization and over-engineering. Since your main goal is to build a solution as fast as possible, you need to avoid unneeded complexity at all cost. This isn’t the time to obsess over minutiae, like the speed of a single database lookup or finding the fastest way to concatenate strings. Worry about those when they truly matter and only if they are blocking you from the outcome you want. Don’t over-engineer, or obsess over the flexibility of your architecture. Build the simplest thing you can, using the quickest solution that you can turn into code right now.
5. Architect for disposability. If your prototype is part of an existing app or codebase, keep your prototype code as isolated from the rest of it as much as you can. Don’t obsess over reusing or sharing code at this point — excessive dependencies can be more complex to change or remove later on. Even copying and pasting code is ok if it solves the problem and makes it easier to change or discard when needed.
6. Challenge your own assumptions. Anytime you come up with a task you need to do, or extra thing you need to build, ask yourself if it’s really necessary. Think through what would happen if you didn’t build it. Sometimes we convince ourselves that an unimportant feature is critical, or that we need to code up a complex operation ourselves when a simple one will do. You might also be thinking of lots of edge cases in your app that may cause trouble, when in fact the likelihood of a user hitting them is very small. The simpler you can keep things, the faster you can build them.
7. Set expectations. Whenever you’re demoing a prototype to a group of non-technical people, make sure they understand that what you’ve built is not a real product. It probably wouldn’t handle more than a few users at once, and maybe it deletes all their data after they close their browser. A pretty UI can often fool people into thinking an app is much more solid than it actually is (and the corollary, which is that a crappy UI can make any impressive backend technology get easily dismissed). Make sure they understand the limits of the prototype, and what it’s capable of. Set expectations for what it would take to really build the product to support real users.
As an engineer seeking to master rapid prototyping, the first thing you may need to do is let go of many of the rigors and disciplines that you’ve been practicing your whole career. Being able to challenge your own way of thinking is a first step that will lead you to have a better sense of what really matters in the prototype you’re building. While you might be writing “bad code”, the value of a prototype is solely in the outcome it helps you prove. What it looks like under the hood isn’t what matters.
Rapid prototyping is a super valuable practice for established businesses to explore innovative new features, or for entrepreneurs to take a first step toward a working product. The faster you can prove or disprove an idea, the faster you can learn from it and iterate on it. At its core, rapid prototyping is a test of your ability as an engineer to solve problems fast, focus on what matters, and avoid distractions and complexity at any cost. At its best, it’s as nimble a development process as you can get.