Trainwrecks; Two Reasons Why Prototyping Ideas is Beneficial

Main photo from versageek.

Like many elements of software design, I feel like I figure certain things out later than my peers. (Thanks Imposter Syndrome!) In this case, I'm talking about the value of prototyping. Of knowing you will be rewriting this code you are making.

For the longest time, forever really, I have been against this. Sure I would make mock-ups of some elements, but I'd never write disposable code. After all, I've been doing this long enough that I can avoid all the pitfalls and design an elegant solution after planning. Oh goodness, so much planning. All my well-thought out code would be perfect and I'd never have to change it. THIS NEVER ACTUALLY WOULD HAPPEN.

What actually happens is you paint yourself into a corner, leaving you with tons of refactoring if you need to change directions.

I'm going to give an example of what I mean.

I have been working on Nickelpinch, an open source finance and budgeting web app for a while now. I've been making iterations of the basic functionality since 2006. (aaahhh!)

In 2014 I decided to rip it all up, and make an actual, real version other people would want to use. I went with Laravel (a modern framework) because it was the best for PHP, however I didn't know it very well. So I spent cycles getting up to speed in that. Then I spent lots of time planning the UX/UI and made templates in straight HTML, that I could use later. I started with what the user would start with; account creation and login. I kept going from there.

Hours and hours of time before I got to actually begin implementing my new ideas for handling budgeting and adding a person's purchases into the system. Once I had that in place, I started testing it all myself. It was bad. Like, super non-intuitive. I kept getting mixed up when using it, and I made it!

There were some design assumptions I'd made that were bad and I had to refactor. Those data models I spent hours on; beautiful structures of normalization? All had to be modified. Which meant all my user functions needed to be altered everywhere, etc. It was a huge time sync.

I'm almost done now (yay!), but I ended up wasting lots of time. (Boo)

If I had made a shaky prototype, no concept of user accounts, sign ups, etc just a test of the core of the app, I would have seen the flaws. I would have saved at least 80 hours too. :/

So there is reason #1 for making prototypes:

It will save you time over all, especially if you have UX elements.

Another reason, and this one just came to me several days ago, is what I call pre-fatigue. It's when I think of an idea for an app or game, and I see the roadmap ahead of me and it's so long I despair and do not even start. I'll explain via another example.

I am designing a sci-fi game, something akin to a turn-based 2D Elite. I want MMO support, I want mobile and system apps for it, I have an ambitious design with lots of untried gameplay methods, etc. Here is what I was planning, from a technological standpoint:

• Core Game Logic in Go, which would be my API
  • Go is great for this, because it's crazy, crazy fast, BUT it is more C-like and it takes longer to develop in than some scripting languages
  • I have never used Go, will need to learn it. Huge time investment.
• Game Client in melonJS, a lightweight HTML5 / JavaScript game framework
  • This would be a mostly empty UX/UI shell that the API would shove content into.
  • I am fairly familiar with JS, but this is a huge step in complexity for me. Another huge time investment.

Just looking at that bums me out. It's a ton of work and lots of that stack I need to learn. Also, my biggest fear; what if, after all that foundation is in place the core game or UI doesn't work well? Shoving all those really good intuitive warnings aside, I started..

I started learning Go, and dove into galaxy generation. I actually made modest progress at this, see my totally working script. It's so fast!

Then I realized, well what if people want to play single player? Having one huge chuck of game logic in Go for the API, and duplicating it in JS would be a nightmare.. I know! I should write the API in JS too, and learn yet another tool, node.js for my server-side JS API.

At this point you should be screaming "Just stop it, stop!". But I didn't stop. I rewrote my galaxy generation + some basic UI elements in pure JS (That means no frameworks or helpers, since I wanted to up my JS skills). This took a while, but I ended up making JS-Space, which is pretty neat.

However, he farther I was getting into the UI elements, the more I was beginning to despair. "What if I spend 40 hours getting this component working, just to totally toss it?". So I stopped development.

I basically have been at this spot for 10 months. Then! I had the thought, "Dude, just make a single player tech demo of the combat. JUST that to start." I saw I was making the same mistake I made with Nickelpinch; building the entire city infrastructure before seeing if it was a viable location.

What a difference it's made to my outlook! Instead of toiling away for years on something before I have anything to show for it, I could have something a little nifty in maybe 2-3 months! Suddenly I am full of energy to tackle this!

That is the second takeaway:

Small prototypes give you something to show for your work, and you get that morale boost of having something to show for your time spent.

So if you are starting a project that has a lot of untested elements, just make tiny tests of each of those. Don't worry about ANYTHING other than testing that one thing. Get all your untested theories tested, see how they really feel when using them, THEN go back and make it the right way.