Hello, hello.
I just want to start by staying thanks to the organisers for coming to the end of the
conference.
The last couple of days have been amazing for me, just to complete revelation that a
conference of this kind can exist.
It is absolutely brilliant.
I also want to thank Meri in particular, because Meri, you spoke in Edinburgh in 2014 - I live
in Edinburgh - and it was a really inspiring talk for me at a time when I was struggling
with becoming a leader and a manager for the first time, so I want to thank you very much
indeed for that, which is why I'm in part in that for that.
Thanks to Meri.
Give her a round of applause for that.
[Applause].
So, as Meri said, I'm a consultant, and my aim is to have enough help, web product teams
to take their UI engineering to the next level, and, as part of my work with product teams,
I've seen a common pattern, particularly in smaller teams, like I'm going to talk about
today.
I've been told to start with a controversial premise is always a good idea with small talks.
And mine is that I believe that single page apps damage businesses.
Like all controversial premises, there's caveats to take into consideration.
This may not apply to you saying, "Ours is brilliant, what are you talking about?"
I love single-page apps, myself, but I've some businesses struggle with the single-page
apps they've created.
We will look at why that might be and what you can do about it in ten minutes.
When we talk about single-page apps, we often use Google maps as the canonical example.
It is rich, dynamic, amazing app.
It's got a long history.
Because it is Google, it has got a big team behind it, and lots of investment.
And we talk about single-page apps in terms of their features.
To give you a quick background, they provide this application-like experience, and we do
that by dynamically changing portions of the page in place rather than going to the server
and retrieving an entirely new page.
In order to do this, we my access APIs to access and update data, and we use client-side
routing and history management so we can retain some of the web's best features, namely deep-linking
and URLs and so on.
We do this by bundling up static assets in JavaScript and CSS, and delivering them to
the browser, at which point the browser takes it over, parses it all out, and runs it as
an application.
So, while we might talk about Google maps a lot as the kind of canonical example, in
reality, a lot of single-page apps, particularly in the business realm are a bill bit more
like this.
This is Buffer.
Is there someone from Buffer here?
Hello!
No, I'm not singling out here buffer at all.
It's a great app.
A lot of these apps are CRUD.
That's not to say they are terrible but it involves creating, reading, updating, and
destroying data with a nice UI over the top of that.
We start out with a grand vision.
This nuclear bunker here has two floors underground of luxury accommodation.
We have a private plane, an airstrip, so we can fly in and out.
On the left there, your own personal missile silo.
So you can take part in nuclear warfare yourself.
That's very important!
[Laughter].
In reality, for smaller teams, it can feel a bill lit more like this sometimes.
It doesn't fulfil that grand vision we had, it's pretty hard to live with, and uncomfortable,
and, despite appearances on the outside, it's expensive and resistant to change and improvement.
So why does this happen?
I'm going to give one example of why it happens.
There are lots of reasons.
But we need to understand what makes it so hard to make a good single-page app and why
it's bad for business if we fail to do that.
So they're easy to make.
I imagine there are some people frowning out there as well.
If you've ever picked up a React beginner tutorial, it's easy to make a to-do list,
something like that.
But it's hard to make them really good and to turn them into good products.
It's exceedingly hard to make make those products good and provide good user experience, simple,
fast, maintainable, and all those things that we expect from that vision.
I'm going to illustrate this with completely made-up evidence, in the form of a chart,
so it has some face validity - a term from psychology.
So, if you were to plot the effort that your team puts in to your app, which is really
the complexity that you're adding to the system over time, against the user value that you're
providing to users, and compare the single-page app approach with more traditional apps like
server-rendered apps that you might get with Rails or PHP, earlier on, there's a good feeling
that you're providing loads of value and you've taken the right decision, but, somewhere along
the way, it gets hard to add extra value.
You get constrained by stuff you've already built, and adding those new features seems
to make the thing worse.
You really need to push through that to the point where you get that great user experience
and performance that really rivals native desktop and mobile applications.
Now, unfortunately, smaller product teams tend to stop somewhere along the way for various
reasons.
It can be because they've run out of money, or the team gets moved on to other things,
your product scope might be bigger than the team can actively support in a very detailed
way.
And, so, what happens here is that you never really fulfil that vision, and you end up
maintaining an application that is in that state of not being quite what you expected.
So, of course, as developers, we naturally blame the tools for this.
As, in the case of single-page apps, that's the JavaScript application framework, so hands
up who recognises all of these logos?
That's pretty good.
About a third of the audience.
Excellent.
I will buy anyone a drink ... [Laughter].
If you can recognise these ones as well?
I had to look some of these up.
So there's no shame in any of that.
As developers, we focus a lot of the time on discussing the since and outs of these
things.
It's enter - the ins and outs of these things.
This is developers exercising control over what we have control over, and we need to
make technology decisions so it's important to understand what these things can do.
But, if we take it to the extreme, and allow to to lead us too far, we can get into the
trouble.
This is the" gardener Height cycle.
When a new technology emerges, it reaches kind of, if it is lucky, it reaches a stage
of hype, and then as more people apply it to more problems, they realise it's not suitable
for absolutely everything in the world, and then eventually, over time, it comes out,
and reaches this plateau of productivity, at which point everyone ignores it and it
becomes boring technology, like PHP, right!
So I wondered if a lot of teams get to this point in the cycle and start to look elsewhere.
[Laughter].
This is kind of happening now with React and Vue to a certain extent, and, if you pay attention
to this stuff on Twitter, it's basically endless.
But this has happened time and time again in the JavaScript community, and, outside
the JavaScript community as well, but it seems to be much faster in the front-end.
And, of course, when we see this new technology emerging we imagine this time it will be completely
different and all our problems we experienced with our current product will be resolved
by adopting a new framework.
Of course, this is quite naÔve, and subject to bias.
We heard some of this earlier.
And in extreme cases, you can end up in this situation.
So this is what happens if you optimise for the developer experience exclusively.
You really just are surfing that wave of hype over and over again.
Of course, this is pretty bad for business if you allow this to happen too much.
Because, what you're doing here is really reinventing that user value that you have
already created in your system using a different technical approach, but these things tend
to stick around as well.
It's not like you're completely replacing them.
You end up maintaining an awful lot of stuff for the same user value.
I only say this because I did this myself on a hypergrowth start -up and fully admit
to having done this naÔvely in my early days as a leader, so, don't feel bad if this is
you.
How do we break this cycle and maximise the user value whilst minimising the complexity
and cost associated with it?
First of all, we have to remember of course that it's not the frameworks that are making
the apps, they're just tools.
It's of course our teams, our team that make the app.
It's worthwhile taking some time to think about our our team interacts and behaves with
the product.
Now, we've heard a lot about some of this stuff this week, obviously, so I'm going to
go through this quickly.
But, things to consider: to you have a clear - do you have a clear understanding of the
product vision in are you aligned on that?
Does your team have good communication practices in a psychologically safe environment for
discussing disagreements and possible approaches?
Does your team have the right combination of skills and capabilities to execute on your
approach that you've taken?
And are you going about things in a sustainable way that will en sure the life of your product.
Finally, do you actually understand what your product does?
This last one's quite surprising to many people, but if you've ever worked on a long-lived
product, you'll know if there's been a bit of staff turnover, some of the documentation
isn't all that great, the test coverage isn't that great, it's quite easy to forget what
your product does in detail.
You miss a lot of the details.
You constantly are surprised at the little things that it does here and there.
Earlier, Uberto talked about rejuvenating an app - I love that term, by the way.
I like to look at this through the lens of Lean software development principles, in particular,
the principle of amplifying learning.
For me, we writing the framework is deliberately forgetting the learning you've made along
the way, and hopefully rediscovering those as you rewrite it.
By contrast, a rework or rejuvenation requires you to learn about your product as you go
along, it harder work, takes longer, painful and less glamorous especially if you don't
get to adopt the new framework straightaway.
This in the long term is much more valuable because your team has to learn been implicit
value in your product.
So, unfortunately, reworking single page app is pretty difficult, because, up to now, we've
kind of taken this monolithic approach to them.
It is only recently that tooling has been in place to allow breaking them up in a much
more sensible way.
One thing you can do is to explore possible ways of doing that.
Really, you want to break it down by user journey if possible, so that means then you
can take the simplest approach that is appropriate for each part of the application and product.
Then smaller apps make it easier to find and eliminate waste, both for your team and within
the codebase of the project itself.
And, of course, this is another Lean principle.
And it involves taking regular small steps over time.
It is not something you want to do all in one big go but it is something you can do
over time.
Really, you're aiming for proven simplicity rather than some assumed level of future desired
state.
So you can use this question to ask yourself and your team about what the appropriate approach
is.
So what is the simplest way to sustainably add and maintain user value.
I think looking at it through this approach, it's really vital for long-lived products
in particular.
Ultimately, the aim is to grow your team's ability to live with your product.
It's a long-term relationship.
Like all long-term relationships, it requires regular sustenance to keep it alive.
Thank you.
[Applause].