At QCon New York 2017 Adrian Trenaman presented "Removing Friction in the Developer Experience" in the new "Developer Experience: Level up Your Engineering Effectiveness" track. Key takeaways included: minimise the distance between "hello, world" and production; code is the primary artifact; seek out and remove friction in your engineering process; and give freedom-of-choice and freedom-of-movement to your engineers.
Trenaman, SVP Engineering at Hudson's Bay Company (HBC), began the talk by stating that for him the notion of "Developer Experience (DevEx or dev-ex)" is about "minimising the distance between a good idea and production".
... build an organisation and architecture that allows you to deploy change frequently, swiftly and safely to production, and own the impact of that change.
A "Developer Hierarchy of Needs" was presented, with basics including things like access to a laptop, WiFi, and a (standing) desk. Perks include free food and beanbags, but the really important need is self actualisation - the ability to get stuff done and have cool stories to impress your friends and the industry at large.
Trenaman discussed how code is the primary artifact from a software development department, and everything should be organised to support this goal, including the leadership structure: development teams are responsible for building, running, and owning services; Directors within the organisation should be accountable for services (and should also write code for at least a percentage of their work time); and Technical Executives are informed on service.
Operating testing and staging environments can be a large resource drain on an organisation, and often do not prevent issues when deploying code to production. Instead, Trenaman recommended that development teams should prefer to test in production. Borrowing from Lean Manufacturing, the concept of minimising waste was discussed, with a core takeaway being to reduce hand-offs between development, test and operations teams.
Teams should test services in production by initially launching dark canaries, launching canaries taking a percentage of user traffic, releasing and observing, and providing automated mechanisms to roll-back if necessary. Teams should be seen as internal startups that provide services to other development teams, and must clearly document the contract and SLAs offered by a service, and also offer accurate and well-maintained sandboxes for external teams to test against.
Multi-tenant design can be exploited in order to allow confident testing in production - a new instance of an application/service/account can be created, and experimentation conducted here is isolated from other tenants. Teams should also be given secure, unfettered access control over their own infrastructure, with segregation and command and control applied only where necessary, for example, when dealing with Personally Identifiable Information (PII) or payment processing (PCI-DSS).
Where possible, technology choice should not be forced onto teams. Instead, prefer voluntary adoption. Trenaman discussed that HBC has created a "Virtual Architecture Board" that is composed of technical leaders across the organisation, who regularly meet and are consulted on architectural and technology choice. In collaboration with the rest of the organisation this team generates an internal Technology Radar, much like the now famous ThoughWorks' Technology Radar.
In an attempt to mitigate the fear of development teams "breaking all the things" when deploying, the HBC team has found implementing applications as microservices has provided some level of isolation, and can prevent cascade failures when designed correctly. Trenaman also recommended the use of serverless technologies, and discussed how HBC has begun replacing parts of the architecture with implementations using AWS Lambda combined with Amazon API Gateway and AWS Key Management (KMS) service for handling user traffic ingress and authorisation/authentication respectively.
From an organisation perspective the development teams in HBC are self-selecting - when a large project or product is initiated the team leaders can advertise and attempt to recruit a team. This can lead to the formation of teams that are fully-aligned and want to work well together, although care must be taken with the mix of skills and senior/junior skill level balance. When projects are running, the teams take care to minimise distractions from coding and delivering business value, and meetings are limited to between 2.75 - 5 hours per week. Recurring meetings are regularly reviewed, and removed if the attendees believe there is limited value.
Concluding the talk, the HBC "People Ops" team was presented, and Trenaman discussed how regular developer surveys attempt to capture objective and subjective metrics of happiness and productivity within teams. The team regularly monitors these metrics, and takes action in regards to team organisation, process, and activities to reinforce the desired culture.
Additional information on Adrian Trenaman's talk "Removing Friction In the Developer Experience" can be found on the QCon New York website, and the video recording of the presentation will be released on InfoQ over the coming months.