It's All About The Engine

Sometimes, not solving a problem in the best way possible is not an option.

If you read my post yesterday, you'll know I'm absolutely fixated on the code that drives the language transformations within Arcade. I like to call it the engine.

It's becoming a really complicated piece of code and it's a huge value proposition to the business. Right now it does its job, but I'm foreseeing some limitations that might hinder its capabilities later down the road.

While most of the code within Arcade can be minimally viable and not exactly perfect, the engine is something I need to be excellent. I know customers are going to be requesting different formats and customizations, so I want to be prepared for that. The current complex architecture may limit those possibilities.

I've re-written the engine once already and I'm considering doing it again. There's so much potential with design APIs, I want to be able to capture it fully and be in a position to respond to users' needs as best as possible. Without a solid foundation, that's going to be difficult.

If Arcade is going to be a source of truth, then fostering the ability to export is a top priority. A source of truth is useless if the information is stuck inside.

It'd be really easy for me to say it's good enough, throw a blanket over it, and not think about it ever again. But for me personally, I need everything to be rock-solid. There is no room for foundational weaknesses that a competitor can exploit. Not solving this is simply not an option.

If it was an option, why would I be doing this? To get beat? Hell no.