Removing Friction in the Developer Experience
Speaker: Adrian Trenaman
See the list of all blog posts from the conference
Started with a funny story explaining his talk was about removing red tape and bureaucracy. To TSA/immigration.
Goal: minimize the distance between hello world and prod. Need to be able to deploy quickly, safely and own in prod
Developer hierarchy of needs
- self actualize – get stuff done and have cool stories that impress your friends
- perks – fuzbul,beanbags,free food – we don’t work for treats. a bit like the breakfast buffet at a hotel; love at first, but then meaningless
- basics – laptop, wifi, vpm, eat, standing desk, screen, warmth, light
Good software org
- Teams 3-7
- Departments 16-24
- Leaders not managers, leaders who code – 85% of time as lead, 60% of time as director, 15% of time beyond that
- DevOps, ownership, open source
Work is hard – like pushing up a hill. Friction is a force that pushes back when try to do something
Friction: Staging/Testing environments
- Too many of these such environments. Waste
- In physical world, draw map of area and make one continuous
- line of what need to do in order to complete job. The resulting spaghetti diagram shows wasted effort.
- Doing this on the environment shows number of people deploying and number of deployments. Helps highlight handoffs between groups of people – dev, qa, deployers.
- Muda – waste in process – Intellect (building environments), Overprocessing (retest in multiple enviroments), rework (environments never match prod), inventory (commits held up), transporation (deliveries to prod), motion (commit/deploy cycles), waiting (held up on someone else) and overproduction (fewer big bing releases)
- Instead deploy directly to prod – dark canary (see if working), canary (one of X servers has new code) release (all servers get new code), rollback (if needed)
- Think of team as a startup providing services to other dev teams
- Teams need secure, unfettered control to their infrastructure. Break down master account into subaccounts. Also helps with cost model because can see which teams use what. Some teams need everything locked down, but not all do.
Friction: Forced technology choices
- Voluntary adoption – let people choose technology. If successful, more will use. If nobody using, see should stop using it
- Looks like chaos, but creating an environment where people can create own choices
- Standards and recommendations on github: https://github.com/gilt/standards
- Continuum of adoption by role and voluntary adoption.
- Eventually converges on a set of norms
Friction: Fear of breaking all the things
- Knowing going to prod makes one cautious
- Gilt is LOSA – lots of small apps – aka “micro-frontends”. Each page considered own app
- Gives confidence that can’t break checkout by changing the product page
Friction: Forced team choices
- Nothing worse than working with people you don’t like
- Leader locks down product manager, tech lead, etc.
- Pitch and let people sign up
- Somehow this works and everyone wants to be on the team. Everyone picks in a room on a board so can see if too many people have same skill set or too many junior people. Ultimately the tech lead chooses. Can negotitate : will do unsexy work if can also work on X. If nobody wants to work on project, think about why can’t get people excited about it. If it is operational work, can spread across teams.
- Teams stay together 12-18 months. Better to bring work to the teams than to self-select teams every few months
Friction: Distractions
- Coding is the primary activity
- Everyone likes being in flow
- Red Hot Engineer – one person is in charge of problems/distractions for a few weeks. If quiet, they can read a book or whatever
- Minimize meetings – they have 2.75-5 hours of meetings a week. Ask at end of recurring meeting if useful and if should meet again.
Measure how doing and compare over time – delivering value, fun, ease of release, health of codebase, whether learning, missing, are we players aor pawns, speed, suitable process, support, teamwork