Whoops! Clearly I'm never going to finish writing up my notes for the
conference last year. Better post what I got even if incomplete, before the
next one begins :-) I couldn't get a discounted ticket this year and won't be
attending. Have fun, everyone there!
UXDX is an interesting conferences, that aims to bring down barriers between
User Experience and Developer Experience people. The conference has expanded
this year, now covering two days. I was happy to see some issues I had with the
conference last year resolved. For example, although the stated goal is to
bring together UX and DX people, improve collaboration, etc, the tracks were
completely separate. Worst for the DX-centred talks, the "room" was a stage at
the back of the exhibition hall and all the noise that entails. This year, the
separation between the two tracks was labelled "Vision" and "Execution" which
made it easier to have talks mixing everything together, and also the Execution
room had a proper room with doors that close. The room was larger than the
section assigned last year too, and always full whenever I peeked in. Both
tracks were always busy. The exhibition hall seemed pretty empty outside of the
breaks, but there were plenty of those - staggered to lessen the lunch/coffee
rush.
There was a handful of talks I was looking forward to, some met my expectations
and others turned out different. Many other good surprises. I'll summarise some
of the talks I enjoyed the most and only include my key takeaways for
others. This doesn't mean any of it was the actual point or meat of the talk,
more like the insights that were new to me personally and that I'll be
ruminating on.
Day One
Micro Frontend Architecture | Luca Mezzalira (DAZN)
I started the day in the Execution room (it sounds a bit dramatic phrased like
this) and didn't really know what to expect with this talk, but it may have
ended up being my favourite one. The speaker stated his problem clearly - how
to make it work with hundreds of distributed developers/teams - and also noted
that the solution he came up with challenges common software development
wisdom, but to keep an open mind.
The idea is to share absolutely nothing. Not even a button. Don't create a
library of shared components, like headers. Really, how often does your header
change anyway? Trust your developers. They can duplicate and maintain this. The
goal is to minimise dependencies. Don't centralise.
The rest is structured based on "Domain-Driven Development." Each team has
their own domain (e.g. Catalogue, Subscription, Payment, ...) and completely
independent technology stack.
The benefits:
- Quicker on-boarding, because you only need to understand your own domain
deeply
- Easier to scale teams
- Freedom for developers to innovate and own something end-to-end
He also mentioned the positive impact on turnover. In London, it's apparently
not uncommon for developers to change company every year, year and a half. This
makes it easy to try new technology which is often the main reason to jump
ship.
There are frameworks that enable this nowadays, like single-spa and frint.
Planning your Agile Architecture | Will Demaine (Fat Llama)
This was an excellent talk, and well delivered as well. The speaker described
the steps you may want to follow to modernise your application and enable a
more agile architecture, from lessons learnt first hand through different
companies. If I had to undertake a project like this I think I'd find the
slides or recording again to refresh my memory first, but for today my key
takeaways would be that this is a long process that you want to tackle
iteratively, so that you can continue to deliver business value along the
way. No one will let you just take off and deliver nothing new for 8 months
while you rewrite the thing from scratch.
Have solid foundations in place (monitoring, feature flags, ...) before
starting. Take your time and do it right the first time or they won't let you
migrate more services!
Another point I found interesting: create a gateway for the clients, the things
that you can't roll back like mobile apps. Even if it's just a proxy to start
with.
Embracing empathy | Tim Hudson (Adyen)
Pie charts bad. Bar charts good.
(Also, look into the Design Sprint / Design Sprint 2.0 books.)
Solving Problems to Build a Compelling Product | Deborah Clarke (Cartrawler)
User research is vital but not the only important thing. Combining with other
incentives can lead to better focus and great breakthroughs. Innocuous, small
moments of delight can increase your conversion rate.
A Journey from Complexity: Reducing Technical Debt | Fabrizio Fortunato (Ryanair)
Interesting to follow the evolution of the RyanAir front page over the decades!
Some tidbits I found of interest:
- Impact of page load. Any speed increase has a direct impact on revenue.
- They use "micro-pages." Concept similar to micro-frontend except it relates
to full pages, each page is its own app. So everyone is only responsible for
their own page independently, and loosely coupled. Single SPA per page, that
can be released independently but still has shared components (interesting
contrast with micro-frontend above).
- They eventually wrote two different apps for mobile and web, as optimising
for one over the other never quite worked and only served in increasing
complexity. Now optimised for each flow. Still haven't decided whether to use
mobile or web format on tablets.
- They use GraphQL, serverless, Brotli.
Design and prototyping | David Hoang (One Medical)
- Prototypes should be low cost and provide high insights. The goal is
learning. Having a prototype together with a vision/roadmap is powerful.
- "Validating" a prototype or design is about gaining insights. About
learning. Not about proving something right or wrong.
- Design is not magic, it's a rigorous process.
- Include User Testing in every sprint.
Prototyping is successful if you get insights that provide value to
your user.
The examples related to medical applications were compelling. From paper
(e.g. stuck onto a 3d printed watch model, to test for smart watches ahead of
releases), to powerpoint, to node-based prototyping, to Figma.
Ensuring the Success of your Remote Engineering Team | Panel
I really liked that the conference kept the talks to 30 minutes, but I think
that's one case where it would have been better to get an extended timeslot,
maybe 45 minutes. As it stands even with only two panelists (+ one moderator)
we barely had time to scratch beyond the surface.
Keeping a budget for internal face-to-face interactions, some kind of annual
get-together has a great impact on morale and engagement and pays for itself.
The cost of saving on office space is not the point (numbers like
€17,000/person in Dublin, €11,000/person in Sligo were mentioned). Talent is
the point. Working remotely helps to attract and retain people.
Onboarding strategies were briefly touched on. One of the companies hires
mainly senior people with 10y+ experience while the other also hires new grads
so the strategies are different. It's great if you can get people to HQ for
this, makes sure they understand the company's values and culture, and also the
tools at their disposal.
To keep people connected, having non-work related communication channels like a
#showyourdesk Slash channel or "whose view is better this week?" can help.
Time zones are a challenge for global meetings. Some expectation that you will
go the extra mile for the business, since you are not tied to a regular 9 to 5.
There were concerns about working from home and whether people are really
working. In general the opposite seemed to be a concern for the panelists: when
people work from home you can't see the black bags under their eyes, or if
people are stuck. People know working from home is a privilege and work hard to
prove themselves. One of the companies measures employee productivity to make
sure they don't burn out - though you have to be very careful about how you
measure people.
The secret sauce is flexibility. Work is only one part of life.
How about accountability and self-determination? Decisions should be made by
the person who needs to. Empower people. Get that right. Measure what you want
success to look like.
With regard to people not contributing, teams are tight and it becomes obvious
who is and who isn't. You do need to be more proactive in searching for
information with remote teams. One-on-one meetings every two weeks to touch
base. They are still refining the process. Seven seems to be a magic
number, you can see if people are performing for any type of team.
Accessibility | Brian Dalton (Aer Lingus)
I missed the beginning but seeing how a user who relies on accessibility
features uses a computer and navigates the Internet is always powerful. Lots of
work to be done still.
From keyboard to navigation to simple, silly things like "times shown in red
are not available." Label your fields.
Five phrases that shout your agile isn't scaling | Tony Grout (Atlassian)
The Agile manifesto 17 years ago didn't talk about how to scale it! From 17 to
70000 people.
Some interesting suggestions that challenge conventional wisdom. My favourite:
it's well-known that smaller teams are more productive. Studies have shown that
teams of 9 to 16 people were 6% less productive than teams of 5 to 9. However,
if you decide to make 2 teams instead you now have twice the unpredictability
because you've added a dependency on another team. Think carefully, run the
experiment to see if bigger teams may be better.
Encourage people to think about "teams" over "team." For example, if the UI
team is currently the bottleneck, instead of engineering twiddling their thumbs
or overengineering something while they wait, perhaps they could create tooling
to help the team. That slows them down and helps the other team.
One team working faster can cause everyone else to go slower. For example, a UI
team wanting to be pixel perfect.
Those closest to the problem should make the decisions.
Kessel Run: A Digital Transformation Story within the World's Largest Bureaucracy | Adam Furtado (Kessel Run / U.S. Air Force)
An interesting choice for a closing keynote for day one.
The transformation described is absolutely incredible. The speaker spent a fair
amount of time at the beginning to explain the current state of things,
years/decades of risk aversion leading to becoming unable to adapt to change
and thus less safe. Twelve to fifteen years to go from an idea to something in
the users' hands, 96% of project behind schedule or over budget, 40% never
delivered... They went to Pivotal, who helped them to learn about modern
software development practices, devops, etc but more importantly how to change
the culture. Now deploying is a non-event and they went from 10 years to 120
days for delivering.
It's truly inspiring and the project they presented as an example showed the
real-world benefits: allowing soldiers to stay safe at home and with their
family rather than go on months-long refuelling missions around the world,
thanks to streamlining the refuelling planning process with
software. Definitely a worthy goal.
It was however a bit strange to hear about software described as a
differentiator and weapon to cultivate on the battlefield, and how to improve
warfare. I suppose keynotes are meant to make you think rather than just give
you warm fuzzy feelings, and this talk sure fit the bill!
