Don’t believe the hype!

So, good afternoon.

It's been a great day of talks.

I've got a laundry list of topics to dig into when I get back up to Byron Bay.

And I know what you're thinking.

We've had so many amazing speakers all day talking about bleeding edge tech.

And here's some clown up on stage to ruin it all by telling you not to believe the hype.

Cheers, John.

I guess that's your idea of a practical joke.

Anyway, here goes.

Apologies in advance, but I'm here to talk to you today about hype driven development.

It's not a new term.

I definitely didn't come up with it.

You may also hear it referred to as resume driven development.

I don't know if any of you have practiced that at all.

Basically, it's when we make technical and architectural decisions.

Based on opinions, social media, and basically whatever the new hotness of the day is.

Now as I say, this isn't a new phenomenon.

It's been around since when I started coding, which as John kindly pointed out was a really long time ago.

So if you cast your mind back 25 years, imagine a more toned me, less grey in the beard.

I used to sing in metal bands, which made zero money, so we couldn't afford web developers.

all the web oh, webmasters, sorry, I should say, as they were called back then.

So it was up to me to design, build websites, and of course, more importantly, our MySpace pages.

Deploying to AWS?

No thanks.

Geocities and Angel Fire, reigned supreme back then.

And in those 25 years of coding, I've seen plenty of projects succeed.

And plenty fail.

I've got a graveyard of projects in a folder on my Mac that haunts me every time I look at it.

And there have been some milestones on my dev journey.

I've FTP'd changes straight to production.

I cried when my WordPress plugin broke.

I brought down a whole website because there was no version control.

I waved the jQuery banner high.

I rode the wave of AngularJS.

I made some beautiful spaghetti soup out of Knockout, and I had my fingers burnt by Ember.

So what's the point of this history lesson?

that's a great question.

The point is, even back then, hype driven development was rife.

And when I was just starting out, the new hotness...

was Adobe Flash.

Hands up anyone who's working on an Adobe Flash project now.

Adobe Flash was the best.

You think it was the future?

till it wasn't.

For those of you unfamiliar about it, it came out in the late 90s at a time when some would say the web was at its ugliest.

For the first time, it brought websites to life with video, animation, and cool interactions.

It was to the point where people became famous for making Flash sites.

In the circles I traveled in, it was divisive to the point where some of my mates said, Oh, I'm not even going to bother with HTML, CSS, pah, JavaScript.

Those technologies are dead.

I'm going to learn Flash.

However, try as I might, I could never wrap my head around the keyframes, or the actions to work the magic that brought to the table.

So I stuck with the fundamentals.

Turns out, that was a good bet to make, but that was the very first time that I remember that fear of missing out or that I was going to get left behind by some technology as the train was leaving the station.

The next time was when jQuery hit the scene around 2005.

That was a game changer.

People were preaching, don't learn JavaScript, just learn jQuery.

Stack Overflow was awash with answers to JavaScript questions that just assumed jQuery was being used.

And you can probably still see that today.

I work mostly in vanilla JavaScript, so 90 percent of the Stack Overflow answers still have all the remnants of the jQuery answers.

And again, I started to get the feeling that I needed this technology in my life, or I was going to get left behind.

Of course, it was a much simpler time.

I was subscribed to Web Designer and NetMagazine, which was the source of most of my web news.

It came through the post monthly, so the lead time on adopting a new technology was much longer.

But these days with social media, new ideas spread faster than they get tested, and way faster than people are really able to understand their trade offs.

Now, to be fair, I think everyone in this room, definitely myself, we're drawn by the allure of the new, by nature.

Otherwise, you wouldn't be at this awesome conference in the first place.

Our thirst for knowledge and playing with new technologies knows no bounds.

It's baked into our DNA, and I'm definitely guilty of this, and I'm pretty sure if I was a bricklayer...

I'd want to be the best damned bricklayer I could be.

I would be subscribed to Bricklayer Magazine.

And yes, this is a real thing.

So I'd have my subscription there, and I'd be following all the mortar manufacturers, looking for something that would give me the edge, or help me lay egg, lay, eggs?

Or lay bricks, better, faster, or more securely.

People would come from miles around to marvel at a Dave Berner brick wall.

And as you can probably imagine with this sort of attitude, I've jumped on a few bandwagons, and I've even tried to lead a few.

One of my personal favorites was when I decided to double down on the Shadow DOM.

The idea of truly scoped CSS was just too appealing.

So I went to a conference, much like this one, got up on stage and waffled for half an hour about the web component spec, convinced Shadow DOM was the future.

Now it turns out there were three members of the W 3 consortium in the audience who pulled me aside afterwards.

They said they love to talk.

It's very enthusiastic.

but unfortunately everything that I just mentioned was all just about to be deprecated.

So I'd effect . I'd effectively just filled the entire audience's head with lies for 30 minutes.

And I was devastated, not least of all because it meant the death of possibly my favorite named CSS selector that you guys will never use, the shadow piercing descendant combinator.

If there is one thing that coding has taught us all, it is that naming things is hard.

Anyway, forget I mentioned that, it's been deprecated anyway.

It feels to me that the last 10 years has really been where hype driven development has come into its own.

The web landscape seems to be getting increasingly complex, whilst the end user experience is getting worse.

We're shipping more JavaScript than ever, build times are through the roof, and our toolchains are getting bigger.

The rate of new technologies coming into the fore is at an all time high.

Which also means the lifetime of new technologies is at an all time low, because developer interest is at an all time high.

looking at the results from the state of JavaScript 2022 for developer interest, it paints a revealing picture.

Now you can see nobody stays top dog for long, and this is just front end libraries.

It doesn't even take into account all the frameworks, which are again in their own category.

Now, this is purely one portion of the tech stack, we're just looking at JavaScript, which to be fair is one of the most volatile, but the same is true of most other layers of the modern web.

Now, this begs the question, of course, where does hype driven development come from?

How does it start?

Why do we have 20 plus JavaScript front end frameworks?

like most things in life, it starts with a problem.

Typically, a specific problem that a company is facing, and some very smart people spend some time putting together a very smart solution, which could be a new framework, a new library, or an approach to architecture.

Now it's worth reiterating that framework, solution, or technology has been designed specifically for the problem that company is experiencing.

It doesn't make it better than other solutions.

It just simply solves their given problem better.

Now that team, very proud of their work, and rightly They've worked very hard on it.

Most likely, they've solved a very complex problem, and presumably, other people are facing this problem too, or will do at some point, so they share the idea with the rest of the world, which is amazing.

This is one of the main reasons why I got into tech in the first place.

The community is unbelievably open and happy to share what it's working on, and I don't know any other industry that is as open as we are.

Then people like me get up, and we talk about the framework we come up with.

We write blog posts.

And these days with social media, these ideas get spread far and wide.

And of course, the message sometimes gets lost in translation, or the original problem isn't fully understood.

Now, this is a sweeping statement.

But generally, I found engineers like me, who read blogs on tech and subscribe to newsletters and magazines in the post are also the ones who are most likely to stay on top of technology and not want to get left behind.

And we're also commonly the most vocal, advocating to rewrite the code base or rework the architecture so we can scale or whatever the buzzword is at the time.

And soon, teams all over the world start using this new tech.

So what's the big deal?

Why does it even matter?

the problem with hype is that it can easily lead to bad decisions.

Both bad architectural and tech stack decisions, which often punish teams months or years after the original team members who were caught up in the hype had moved on.

And I'll be the first to put my hand up and admit I've been the worst for this.

The biggest one for me was, it was React.

Now why does React exist?

Oh no, I'm going to upset some people now.

So why does React exist?

It was the brainchild of some super smart engineers at Facebook.

Because as Facebook got bigger, its code base got massive.

Thousands of engineers were working on tons of features, getting added every day.

Code maintenance became difficult.

The features slowed things down.

They had tons of network requests.

They needed to move things to the client.

They had a problem with state management and changing events that made it really hard to track what's going on and keep the app state consistent.

Facebook was, React was born.

Facebook promoted React.

Hard.

They actually put on React tours and pushed the new paradigm with buzzwords like 'functional' and 'Virtual DOM' and 'single way data flow', and they built a whole community around it.

They actually did a React.

js world tour, which was just conferences all around the world, and me and the rest of the world went "Facebook's created the framework of the future.

Let's rewrite everything in React".

There were static sites being rewritten in React.

There was blog, all sorts of nonsense.

and at the time, the company I was working for, we were about to start a new feature.

They already had jQuery, Knockout, Underscore, and Angular 1 in the code base.

And they were talking about the big rewrite to Angular 2.

Now, I don't know if anyone else tried the migration from Angular 1 to Angular 2.

I can tell you it's not easy.

at that time I said, if we're rewriting everything from scratch, let's forget Angular 2, let's use React instead.

What's one more framework on top of the pile?

Now, at least we did one smart thing here.

We built out a prototype of the feature in both Angular 2 and React.

We went back to the Eng team to evaluate and React was chosen due to the component based architecture.

and it felt a little bit closer to JavaScript than Angular.

Angular to me, honestly, just feels like you're learning Angular and not really writing JavaScript.

Probably a controversial opinion.

but ultimately it came down to, it's what got the engineers excited.

It was the new hotness and we were pumped to use it.

Now, of course, none of us were React engineers, hadn't even been out that long, and the code quickly turned into looking like a dog's breakfast.

We'd also fail to evaluate whether a front end framework was even the right tool for the job at all.

And what's worse, we then hired another engineer who was obsessed with functional programming.

I like functional programming.

I'm not against it, but it's I really like it.

I think we should bring Ramda in and put that on top.

And he seemed super smart and the team respected him.

So we just went with it.

None of us work there now.

And the code base has now got more libraries than I've had hot dinners.

That was a massive learning for me.

Years later at an interview, the interviewer asked me, if you're starting a new project, what front end framework would you use?

I asked him if it was a trick question.

He assured me it wasn't.

He said it didn't matter.

I said, of course it matters.

The first question I'll ask myself is, what's the actual problem I'm trying to solve?

If the new project's a chat application, I'd be looking at technologies geared towards real time updates.

If it's just a CRM, there's probably no need for a front end framework at all.

You might be better off looking at a traditional server side solution.

A front end framework is just one of many tools for building web applications.

It shouldn't be the de facto solution.

Often these solutions are created by large companies with huge teams that can manage the complexity.

So I'd ask myself, can I keep it simple?

Do we need a front end framework at all?

He's looking at me now I'm not sure about this guy.

So keep in mind, Twitter scaled to 200 million users on Ruby on Rails.

Facebook became a multi billion dollar company running on PHP and C++.

And MailChimp was using...

PHP to send more than 400 million emails to 7 million registered users.

Now, the interviewer looked at me like I was insane, and it may not surprise you to learn, I didn't take that job.

But as you can imagine, a question I get asked a lot is, Dave, you're you're supposed to be a front end engineer.

Why do you hate front end frameworks so much?

And to be clear, this is absolutely not the case.

I've learned loads by reading into them, learning how they solve problems, playing around with the technologies, creating side projects to understand the trade offs.

But I do worry we might have taken it too far.

I was doing some consulting work for a mate of mine who had a perfectly good .NET monolith.

I can hear the groans from here.

It's a tiny little shop.

He was somewhat technical, and he liked to get his hands dirty.

So he's speaking to the team, and this is a conversation between him and his team.

Full page experiences suck.

Let's tear down the monolith and create React apps.

Is that cool?

Okay.

what about routing?

Routing.

Sorry.

We're in Australia.

And, state management.

Oh, that's fine.

We'll, we'll add a library for that.

Okay, I just Bower install it and update my Gulp pipeline?

I've just moved on to it from Grunt.

No, forget all that.

Stuff's way more streamlined now.

You can just use Create React App.

It has Webpack under the hood.

Does all that for you.

A few months later.

Ah, the app's running a bit slow.

Can you take a look?

Yeah, so I've had a look, and it seems React have moved to a new version.

Have you updated to React 16?

Uses the new Fiber architecture that solves all that.

Oh, great.

So I just, npm install the update.

kinda.

What do you mean kinda?

no one uses NPM anymore.

You've got to use YARN.

Okay, cool.

All right.

I just run YARN and I'm good to go?

kinda.

What?

it's a major update, isn't it?

What does that mean?

possibly some of your other dependencies won't work anymore.

There's definitely going to be breaking changes.

You're going to need to, I reckon, three, four months.

We'll rewrite it.

We'll get it ready.

Great, okay, fine.

Let's get it on the Kanban board.

And you might want to consider moving everything to hooks.

No one uses class components anymore.

What's a hook?

Oh, it makes your code cleaner and easier to reason about.

What does that mean?

Oh, no one knows.

I just read it somewhere.

I thought it sounded good [audience laughs].

Cool, I'll use that in the next meeting.

Oh, and React Router has changed its API too, so you'll have to update that to work with the latest version of React.

Cool, NPM, no, sorry, Yarn, and it will work?

kinda.

Oh, go on.

people are using PMPN now.

And also, to work with the latest React Router, you'll want to change most of your setup.

But it's alright, they've written a handy migration guide you can follow.

Okay, how long?

Yeah, maybe two, three months?

Get it on the Kanban board.

Okay.

Great, I've updated my code.

I only took a few quick months, but my Webpack build doesn't seem to be working anymore.

Webpack?

You want to move to Snowpack?

maybe Vite, actually.

What's Vite?

it's Webpack, but it's better because it's written in Golang.

Why?

I'm not sure, really.

I read it somewhere.

I think it's faster or something.

Although...

Go on.

no one's really using React by itself anymore.

Really?

Yeah, even the React team seems to be recommending you use it with a framework.

Okay, cool.

What do I need?

most people are on NextJS.

It handles all that pesky routing, routing, and sets up the API for you.

Oh, cool.

Okay, I'll migrate.

How long is that going to take?

Ooh, how long you got?

All right, you're going to need to hire at least two more engineers, probably a Node engineer as well.

Okay, let's get them in.

I'll migrate.

Skip to a year later.

It's all rewritten.

Dream scenario.

My, my Lighthouse performance scores still suck, though.

Yeah, obviously, because you want server side rendering.

Sorry?

Server side rendering, where it renders your app on the server first.

This sounds an awful lot like where we started two years ago.

Yeah, but this is way better, because it's got hydration.

Sorry?

Hydration!

It keeps everything in sync!

I'm getting some wild build errors now.

of course you are.

That's because your hydrated state and your SSR are out of sync.

Tell you what you need.

Islands architecture.

This would definitely be faster and more efficient if we just kept things the way they were.

Don't be such a dinosaur.

Gotcha.

My mistake.

How do I solve it then?

you could move to React server components.

Or, migrate your code base to React 18.

I hear that's pretty painless.

Or, I hear Angular have just released the catchy full non app, non destructive hydration.

And as I said before, naming things is hard.

I've heard so many conversations that go like this.

It's just not even funny anymore.

Anyway, it's not just technology that's prone to hype driven development.

One of my personal favorites, because now I just want to upset any product managers in the room as well, is Agile.

Agile.

Yep.

Who here has been to a daily stand up?

Beautiful.

Now, keep your hand up.

If the majority of that stand up, you're not really paying attention, you're just thinking about what you're going to say when it's your turn [loud laughter from the audience].

Stand ups are the worst.

I work somewhere, they'd have a 10 minute stand up every day at 10 a.

m.

Inevitably, no work got done between 9 and 10, because people are like, I've got stand up at 10 anyway.

I'll have to context switch.

I can't start anything chunky.

That 10 minutes turned into 30.

Most people don't want to be there except for the overly enthusiastic agile coach!

Come on guys!

10:30 stand up's over.

I might as well grab a coffee before I get back to my desk.

Stretch the old legs.

Sit down to my desk at 11.

It's only an hour till lunch now.

I just replied to some Slack messages.

That's half a day lost.

Got to work in two week sprints with a kick off estimation session every other Tuesday.

Another day absolutely lost.

So much for individuals over processes.

How can you possibly estimate a task?

The real problems only reveal themselves once you're doing the actual coding work.

Let's just call it what it is.

Guessing.

This methodology was touted as the holy grail of product development, and PMs all over the world jumped on it.

And before we knew it, our teams are organized into squads following the Spotify model, which they ditched almost immediately, by the way.

We drowned in a sea of story points and t shirt sizes, patting ourselves on the back for the physical board we wasted a day writing cards out for.

I actually think the original manifesto is great.

Individuals and interactions over processes and tools.

But somehow we've ended up in a world of processes and tools and not doing the actual work, because no one's stopped to think.

Is this the right solution for your company?

How can you strip the process out?

There are countless examples of hype flying around.

And I'm just to upset everyone.

I'll make sure they're all called out.

Serverless, GraphQL, microservices, micro front ends.

The most prevalent at the moment seems to be AI.

Every company's saying they've got an AI component now.

Even if all it's doing is auto generating names for projects [laughter].

Remember, these tools, they were designed to solve specific problems.

Awesome.

So how can I avoid it?

How do I stop getting swept up by the hype?

Start with the actual problem you're trying to solve.

Does it need to be solved by tech at all?

If so, evaluate what adding this new tech or system to your company will actually achieve.

What other options are available to solve your problem?

If you are reaching for a new hotness type product, make sure you understand the problem the technology was designed to solve.

Go and read the earlier docs and the explorations that the team that created it made, not just the hype related ones by idiots like me.

Think about what would happen if you did nothing.

Would your app fall over, or is it actually still going to be fine in two years time and you haven't wasted two years on a rewrite?

What happens when the new technology gets updated or superseded?

There was a great talk earlier on the way that we have to manage that complexity now and being able to actually update our dependencies, if you weren't able to there, I recommend re watching it.

Invest in the fundamentals.

Should you even consider solving the problem yourselves?

Controversial.

But you've hired smart engineers.

Yes, you might end up creating your own framework, which apparently I hate so much, but it will be one that's tailored for your specific problem, not a one size fits all approach and everything that comes with it.

So just some final thoughts before I go.

I just want to make it absolutely clear that everything I've said today is to be taken with a very large pinch of salt and a healthy dollop of irony.

I love JavaScript.

I love playing with new technologies, and that will likely never change.

I have nothing but admiration for the teams that have spent blood, sweat, and tears solving complex problems and sharing their solutions with the world.

We have the best community in any industry, and this conference is firm proof of that.

However, I'm a firm believer in pragmatism.

As an engineer, you should always be asking yourself what the best solution to your actual problem is.

Do your own research.

Make prototypes.

Run tests, understand the pitfalls, pick the right tool for the job.

And the answer might be blockchain and smart contracts and micro front ends and serverless.

Or it might be the majestic monolith with a sprinkling of vanilla JS.

It totally depends on the problem you need to solve.

There are no silver bullets.

Don't believe the hype.

Thank you.