How to Prototype Quickly: Six Tips for Light-Speed Programming

I’ve completed a few projects that involved prototyping software in a very short timeframe. This situation can differ drastically from the normal pace of agile projects because results and certainty have to be prioritized above long-term considerations.

If you find yourself in a situation where you need to push code out quickly (and won’t be building on that code over time), here are some tips for delivering that high-quality prototype on time.

1. ABC: Always Be Coding

We all know that coding is only one part of software development. The software needs to be designed and turned into stories, the execution needs to be planned out, and the code you write needs to be tested and validated. A lot of this activity involves collaborating with others, whether co-developers or other stakeholders. This collaboration is necessary for answering questions and making good decisions, but it’s also time consuming.

Don’t let that keep you from cranking out the code that will need to be written. More code means you’re a little closer to a complete prototype. Seeing that progress, even if it isn’t part of the core functionality, will help you and the team measure progress and keep morale high.

2. Remember the Pareto Principle

The Pareto Principle states that 80% of the effects come from 20% of the causes. When it comes to short-scale prototyping, you can’t afford to spend time on the 80% of low-effect work.

Spend some time upfront thinking about all of the possible low-impact and high-impact actions so that you can prioritize correctly. Then continue doing this throughout the project. Never be tempted by a low-impact action, even if you might prioritize it highly for a normal project.

Examples of low- and high-impact actions will depend on the goals of your prototype, but an example low-impact action might be adding string localization or an error-reporting service such as Sentry.

3. Don’t Forget to TDD

Limited time on any project is often used as an excuse to forgo TDD. I think that decision might be valid if you aren’t using the Pareto Principle described above. However, if you’re starting with the right tests and keeping the framework simple, then TDD will actually save you time throughout the project.

This has very little to do with catching errors. TDD leads to good code design and architecture and will help you reason about your code. That’s very important when you’re coding quickly and don’t have time to refactor continuously.

4. Write Code that’s Just Good Enough

Amazing code takes a lot of time, deep thought, and iteration to achieve. Good-enough code takes a lot less time, and it won’t create tech debt quickly enough to cause any problems.

When your time budget is small, and the prototype will not be used for a real product, do not bother writing amazing code. Your code should be clean, easy to understand, and easy to change, but don’t focus on elegance, extensibility, or reusability. No one will be looking at it to admire that elegance or make use of the reusability two years from now.

5. Avoid the Sunk-cost Fallacy

Under normal circumstances, you might sometimes want to solve a hard problem for the sake of learning, or fun, or pride. Now is not the time for that. As soon as you realize that some bit of code is taking longer to write than you anticipated, consider immediately scrapping it or at least shifting course. Feel free to take shortcuts as long as they won’t jeopardize the whole mission.

You might need to put up with some duplicated code or pull in an extra library, but that’s okay. Focus on the prototype, and think of the code strictly as a means to achieve it.

6. Stay in Familiar Territory

Obviously, a time-constrained prototyping project is not the right time to learn a new programming language. But beyond that, try to use libraries, services, and patterns that you’re familiar with and feel very comfortable using. You’ll be able to leverage all of your past experiences and stay focused on things like logic and domain decisions instead of technical ones.

Any new tools just add risk to the project since you never know when you’ll encounter a rabbit hole. Even if that NPM package you’ve never used has 30k stars on GitHub, you should not assume that it won’t create any headaches.