The Problem with Prototyping

I’ve been building support systems for our consulting and staffing enterprise at MJL Projects. There’s a whole different argument about buy-vs-build (you need both really) but that’s not my topic today. This is about building, and in particular, prototyping.

When you build something new it’s… new. You haven’t done it before, even if you’ve done parts of it, putting those parts together this way is new. So, you fiddle around… try some libraries… write some functions… test some data… and then… WOW! It works!

This is the exciting bit, when you can demo your prototype. It’s not “alpha” code, it certainly isn’t “beta” but… in these days of continuous integration and delivery, we don’t really have those distinctions anymore. It’s just code that works.

And here’s the title of this article… the problem with prototyping is that it’s not production ready, and yet… somehow… it ends up in production. Months later you realize you had hardcoded a vendor key into a script that you meant to turn into a config file. Or that synchronous callout which works fine when you have five people using the code suddenly chokes because you have 500 people hitting it at once.

It's not that a prototype, a demo if you will, is inherently bad, or that it’s always filled with shortcuts and temporary solutions (say it with me… “there is nothing more permanent than a temporary solution”), it’s that our habits are different when we’re trying to figure out a problem than when we’re working on production systems.

Think of it this way. When you work from home, you can get away with wearing a decent shirt and pajama bottoms. You look fine on Zoom, so you don’t waste time with polishing your shoes and finding a pair of slacks (or a belt), because you don’t have to. But if you suddenly found yourself in the office barefoot and in sleeper shorts… well… let’s just say you’re not production ready. You have to go home and get some pants, dude.

I have a core belief that once you demonstrate a prototype, you need to rewrite it from ground up to release it. I’ve been doing this with my MJL code… manually lifting one function at a time from my prototype code to my production code. It helps that I changed languages when I finalized my architecture, but that doesn’t matter – you see things differently the second time. Good authors do this with their novels, good engineers do this with their code.

I know… in this era of barebones software delivery teams, we tend to accept a lower standard or MVP (minimal viable product). If it works, it goes into production. I’m not saying that’s wrong, I do it myself. I’m saying that it IS going to break. Honestly, all code breaks. It gets out of date when the supporting libraries are updated, or a new vulnerability ends up in the hands of script kiddies or bots and you need to rewrite a whole section of code.

The question is, do you want it to break while hundreds if not thousands of people are looking? Or do you want it to break when it’s just you in your pajamas?