Software Doesn't Have Clay

At the front of the design process (the far left of the scale), software has sketching, but a sketch's job is to give you the gist of a design while necessarily being unrealistic - literally a fuzzy, lower-dimensional projection of a thing. So you can trust the sketch to give you a quick, imprecise picture of a system, but you can't manipulate it or experiment with it.

Software has manufacturing processes. It has best practices. It has automated testing. The way each of those things influence the overall design is via feedback from developers/operations/product about the relative difficulties and costs of your chosen deployment strategy. In other words, by the time we’re here (all the way to the right side), it’s too late for clay. Things have been cast in metal, parts are being shipped, and we have to write a QC checklist. FAR too late for clay. You've already spent the money, so the only way you can alter the course of the project at this point is by de-scoping, meaning cutting stuff off until the burndown chart looks correct.

But as for the middle of the design process - the moment after the sketch but before you decide which wires connect where, or whether you want to run it as microservices or a monolith - that’s the place for clay. Something that shares dimensionality with your actual solution, allowing you to visualize it in its native space, without the inherent time and complexity of rendering it in its actual materials and fitments, but also with a fluidity that makes change easy, especially changes that are nearest in shape.

I wanna build software clay. Something that lets me give someone a realistic feel for a whole system WITHOUT BUILDING IT FIRST. While still leaving things largely undecided.

It would have to give us some things to be useful.

1. It would need to be able to both shape and validate our assumptions about the system‘s expected characteristics, performance, and refactoring patterns. Stuff like:
   • “given this architecture, here’s how you would add a piece of data to a user’s profile”
   • "what things does the latency of this endpoint depend on?"
   • "what are the implications of adding action A, every time event E happens?"
2. It would also need to be able to serve as a scaffolding for the implementation - that could take many forms:
   • codegen or project templates
   • api-spec
   • or even just a sequence of JIRA tickets

In other words, it would need to serve as a both framework for forming insights about the system (useful now) as well as be an efficient use of time to learn and operate (useful later).

Getting an app out there is costly. It involves enumerating all the weird cases in your business logic, creating helm charts, deciding which cloud provider you're going to use, or which database you need, or what serialization library works best for you, etc. None of those things are what your app DOES.

A software-as-clay system would let you describe what your app DOES. It would let you walk around in the possibility space near a place you've chosen, allowing tweaks to be made as you go. In some cases, it might be able to provide default implementations for enough pieces that actually running a crappy prototype version of your app is possible on day 1. If not, it should be able to tell you WHY not, as in "which missing functionality is preventing me from deploying a crappy but end-to-end app".

What we need is something that's able to be shaped like your app, but without all the hassle of actually BEING your app.