The most impactful engineering leader I ever worked with was a guy named Bill Scott who led UI engineering at PayPal. What I loved about Bill was his constant enthusiasm for new technology. He helped lead the charge to take PayPal's old C++ and Java stack and modernise it into Java microservices and Node.js for the front end. And just absolutely surrounded himself with people who were looking for ways new technology could be used to create better experiences for our customers and improve the lives of developers.
If he were still with us today, I think he would absolutely love the AI revolution taking place in software development right now.
When I was interviewing at PayPal back in 2013 I spoke with him a an influential blog that he'd written called The Experimentation Layer. Reflecting on his time at Netflix, he was pushing back against the cult of reusability in software development and talked about designing for throwaway-ability instead. He was a huge proponent of Lean UX and A/B testing. In the article he mentioned that in his time at Netflix, after something like a year, only 10% of the front end code stayed the same. It was constantly being optimised and improved to deliver better outcomes for their viewers.
He wasn't anti-reusability. He wrote an entire book about building reusable components for UIs. One that was extremely important to me as an early engineer coming up in the jQuery UI era through the HTML5 transition and the death of Flash.
But regardless, it made me a little bit annoyed. It put me off. I had just come from a role where, for the past two years at oDesk, I had been building reusable component libraries. And so we sparred a bit, gently, in the interview. And he helped me understand where he was coming from.
The goal is to build the best experiences for users as quickly as possible. Not being afraid to experiment and try new things, especially when the status quo isn't working. The biggest thing in his philosophy was just constantly getting user feedback and making sure that what you're putting out in front of users is actually working for them. And making sure that you have the infrastructure needed to iterate frequently and measure and observe your successes and failures. The other lesson that I've taken from that time is not to be married to my code. It's just code. It's an experiment. And it's okay if we decide to throw it away.
The calculus of how "throwaway-able" your code needs to be depends on where it lives in the stack. He uses this funnel to illustrate the volatility of different parts of the software stack:
If you're looking at a modern React application, you might think of it like this instead:
In modern client-side React architecture, there are places that we need to be more careful about changes than others. But there are places in a large codebase that ultimately don't matter so much. I think for many people, for better or worse, if a bunch of Tailwind CSS classes change in the code for a component used in only one place, you're not really bothered about it as long as the thing looks like it's supposed to look.
In a different context, you can also think about which features are likely to be sort of permanent and which features are temporary, like landing pages, right, or some kind of feature-flagged experiment you don't expect to really make it.
Death of the Code Review
There's been a lot of talk lately about the death of the code review. I think it's premature, at least for teams supporting real codebases with real users. If we use Bill Scott's framework for determining which code is likely to change frequently or should be designed for throw-away ability, I think that can help us understand where it might be OK for a little "slop" to enter our application without looking too hard.
The way forward with this deluge of AI-generated code isn't to avoid reviewing it; it's figuring out where human review matters the most.
Anticipating UI Engineering's Future
Today, I asked Claude if it wanted to play a game, and it generated one and let me play it, right in the chat interface.
Vercel's also been working on tools to allow chats to render UIs in line with all sorts of guardrails and rules in place. It's called json-render and it's promoting this concept of "generative UI".
Sunil Pai at Cloudflare recently hypothesized about about "code mode" sandboxes that generate custom user interfaces for individual users while at the same time suggesting the chat bots aren't the end game for UIs either.
It's clear that the paradigm with which user interfaces are built for customers is changing and that future hasn't been fully written yet. Dynamic AI-generated user interfaces are likely coming one way or another, and that UI code likely isn't going to be reviewed by humans.
Even so, I'm pretty certain the architecture underlying those future interfaces will be reviewed and tested very carefully by human reviewers. Nobody wants to build their house on foundation of slop. But the "experimentation layer" part, the part of the code we're less fussed about. I'm pretty sure that part is going to get a whole lot bigger.
RIP Bill. You were a real one.
Top comments (0)