> “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
This is _such_ a good article -- although it's not _just_ CEOs that make this mistake!
I've used the "Icerberg Principle" to explain this kind of thing many times. And it's true not just for AI but for almost any kind of non-trivial, production-grade tech. The things under the water cannot be an afterthought; they're essential. The problem, however, is that people without what I call "sympathy for software" often fail to see this nuance and complexity.
As an engineer, it's no use lamenting this fact or expecting things to be any different, because they will _never_ change. Your job as a CTO ends up morphing into the "Chief Vocabulary Officer", where you need to communicate these complexities in ways that people _can_ understand.
Not AI specific but Joel On Software covered a lot of the same material and thinking, written a lot better, about 20 years ago - but that is because this is an evergreen problem - getting leaders to understand that a prototype is just a test or a demo, no a path to the solution.
A previous company had a rule that all prototypes were built with the express intention of throwing them away - no prototype code could ever make its way to live.
As an infrequent user of iMovie (and a past user of Xcode), I think that iMovie really gives Xcode a run for its money in bad UX. How that app got out of the lab like that is profoundly beyond my understanding. It’s not just bugs as such, but actively user-hostile as though a team of people really worked hard with the goal to make the most infuriatingly inconsistent and unintuitive app imaginable.
> “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
I have this up on my wall and refer to it constantly (for both tech and non-tech challenges).
Sorry, it didn't land for you. It's something I've used for a while ("glass" for the screen, and "tin" for the back-end). Perhaps I'm showing my age or my Aussie slang. Thanks for reading, in any case!
You use the phrase twice in the article. Could I ask you to put an asterisk by the first one too?
(I came across it, stopped reading the article to Google it, couldn't find it so came to HN to search the comments and then went back to the article and saw the asterisk later on)
I’m genuinely surprised how much controversy this statement has caused. It’s something I’ve said many times in a professional environment and literally no one has ever picked me up on it. Makes me wonder if they were _ever_ listening …
Hahaha! dw, no controversy from me, just googled it's meaning and couldn't find an answer, so was confused. (and wanted the asterisk to help the future people out)
It could be a more local idiom common in your company/area or something?
I'm curious about the areas you've struggled with, particularly number 3.
I have found the DevX to be particularly great and one of the strongest aspects of Elixir. I abhor JS as a language (I know, I know, I'm fully aware of my biases!), and the tooling and complexity therein are infuriating. I find React and JS, in general, so impenetrable that it has stopped me from making progress with front-end development. However, with Elixir/Phoenix/LiveView, I have created a more-than-credible web front end that would have otherwise taken a React-based team weeks, if not months, more time and complexity. I also haven't seen the kind of recompile problem you mention, as HEEX changes are reflected immediately in the browser on save (at least in my setup).
I do take your point on Fly.io, tho. I am currently operating at a very small scale, and I have been experiencing regular uptime issues. I'm in the process of working out what to do about that as I scale.
Thanks for taking the time for that considered and nuanced response. Much appreciated!
> I'm curious about the areas you've struggled with, particularly number 3.
At the beginning things were very quick like your experiences. It's when we built up a larger code-base (we're currently at ~100K Elixir LoC -- excluding tests) over the last three years, that making a change in a file triggered hundreds of other files to recompile and that cycle took ~10s on modern machines.
> I abhor JS as a language (I know, I know, I'm fully aware of my biases!),
Yeah I hear you. What changed my mind was actually TypeScript -- it's the most advanced (and approachable) type system I've worked with. Take a look at the GIF here: https://kysely.dev/ -- all of the auto-completion is powered by TypeScript.
> However, with Elixir/Phoenix/LiveView, I have created a more-than-credible web front end that would have otherwise taken a React-based team weeks, if not months, more time and complexity.
It's hard to gauge. My assumption is that the big gains would come from having a single language framework (e.g., Phoenix/LiveView vs. Node/React).
> I do take your point on Fly.io, tho. I am currently operating at a very small scale, and I have been experiencing regular uptime issues. I'm in the process of working out what to do about that as I scale.
FWIW we haven't had any issues after migrating to GCP -- even though the setup is more hands-on (VMs). I'm not sure there are other turnkey robust solutions if you want clustering.
I think the last big unknown will be the entire AI aspect of things. I see competing possibilities:
1. AI enables faster development for Elixir & ecosystem -- allowing them to e.g., address issues faster and shine more clearly
2. AI accelerates consolidation and before you know it every new project is fullstack NextJS and old projects are re-written to migrate onto it
Perhaps the most important will be feedback to the LLM (e.g., in the form of static analysis and running tests) -- TypeScript has a huge advantage here IMO. We got to a place where we had basically no runtime type issues (e.g., NPE, exceptions/crashing of FE) in our startup with TS on the FE. Have only heard of similar stories in cases in more niche FP languages like Elm
I won't comment on TypeScript (other than to bemoan its JavaScript origins), but for what it's worth, people I hold in high esteem have a lot of good things to say about it.
But as far as LLM-assisted coding goes, the pure functional / no-side effects / immutable data properties of Elixir (and to be fair, other functional languages that owe their ancestry, in part, to Lisp) seem to have a big impact on the LLM's ability to reason about change. At least that is my experience with it over the last 6 months or so.
It's such a fun time to get the opportunity to muck around with these technologies, "programming" is _profoundly_ changing under their influence.
> “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
[0]: https://personalmba.com/galls-law/