Notes and thoughts from attending the YOW Melbourne conference.
–
Andrea Magnorsky gave a talk[1] on Bytesize Architecture Sessions[1]:
Bytesize Architecture Sessions are a workshop format that help teams understand the systems they work on. Each session focuses on a small slice of a system. After some sessions your team will become more homogeneous in the understanding of their systems, grow a consistent vocabulary and ultimately build tools to design the future together.
I was interested in why these sessions proved valuable. Ultimately summed up by:
“We ship what is in our programmers’ brains” – Andrea Magnorsky
That is, the only models of systems that are practically valuable are those which sit in the heads of engineers working on a given project. The models and knowledge that sits in the heads of project managers, product managers, designers, engineering managers, engineers who aren’t working on the project, external domain experts, and the internet-at-large may be valuable but they don’t necessarily match what is being implemented. Emphasis on implemented – what is implemented may not be “correct” or desired.
The assumptions of engineers get shipped, not the design.
And why is this difficult? Because of the dimension of time. Relative distances between models change. The model in the head of the engineer working on the project updates in real time. The model of the designer who understood the initial requirements hasn’t changed. The model in the head of an individual who last worked on this thing twelve months ago has deteriorated.
The way Magnorsky spoke of Bytesize Architecture Sessions was similar to that of a Post Incident Review run by Safety folks. None of this “five whys, root cause analysis, generate me a list of action items so this never happens again” crap. But a post incident review where people involved in the incident share their mental models of the system and what happened during the incident. The value and outcome of the PIR is for all of those involved to update and correct their models.
“The purpose of an investigation is to understand how things usually go right as a basis for explaining how things occasionally go wrong” — Erik Hollnagel
With a more accurate model of the system, we can act to improve it. If you’re new to these ideas check out the Etsy Debriefing Facilitation Guide. Shared understanding is hard to build, and PIRs aim to build it after an incident. Bytesize Architecture Sessions can be run at any time.
Meeting formats aside, engineers create and ship the models they have in their head. No amount of detail in a JIRA ticket, work plan, or list of requirements is going to make the project a success if the mental models of engineers and other contributors are too far apart.
–
“Abstraction is a disciplined form of ignorance” – Jim Coplien
–
Technical Leadership is the act of a aligning a group of people in a technical context – Pat Kua
–
Allan Hollub started off by talking about Larman’s Laws of Organisational Behaviour[1]. In full:
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, “religion”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
4. As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3), and creating the false impression ‘the change has been done’, deluding senior management and future change attempts, after which they become industry consultants.
5. (in large established orgs) Culture follows structure. And in tiny young orgs, structure follows culture.
As Hollub framed (2), (3), and (4), when something is new one has to do a lot of work to understand it. It’s a high cost (to the individual) to learn the new thing, it’s a low cost to operate in the status quo. It’s easier to just say that a change has occurred, perhaps by giving a process a new name, and applying the process of the status quo. See: Postmortems and Post Incident Reviews. PIRs that aim to find the root cause of the incident and ensure that it never happens again are just Postmortems and a waste of an opportunity.
While perhaps a comfortable frame for those frustrated at the corporate world, it’s too reductionist.
My critical take of Larman’s Laws is that organisations do enact high impact changes, but don’t acknowledge or validate the (usually negative) costs of the change. Individuals are faced with these impacts, so attempt to resort to operating in the status quo. There’s inherent pushback within the organisation. Some examples I’ve seen:
- In layoffs, reorgs. Engineering Managers go from having 6 direct reports to 12. Their workload doubles overnight, but their workload is not reduced in other ways.
- New product initiatives – AI, AI, AI – given to already high performing teams. Now they have to maintain and ship their existing products, while sprinting for a marketing-driven deadline launch of a new product.
- ‘Your critical priorities are …. [7 items]’
- ‘Should we invest in the security of our application or the delivery xyz?’ ‘Deliver xyz while ensuring that everything you run is secure’
Change is easier if it’s acknowledged. If an organisation is asking someone “to do more with less”, at least acknowledge the fact and respect them. (Where ‘organisation’ is a proxy for the individual who thought of the unpopular change and doesn’t want to be held accountable). At a minimum this ‘organisation’ should say what has been deprioritised, previous work that it’s no longer doing, or stack ranking the priorities of everything. New stuff is difficult. Call it as such.
–
Estimation and planning has diminishing returns. At some point just start the bloody work.
For months long pieces of work verify, validate, and revisit your estimates. Doing up front estimates and never verifying them signals to people that they shouldn’t trust your estimates.
–
Flexible Working makes mob programming less common. Pre-2020 we were in the office most days 9am - 5pm. Engineers in a team sat together. We’d do mob programming because we were all there.
Remote, hybrid, flexible hours, engineers in the same team distributed across timezones contribute to fewer occurrences when many engineers are simultaneously available.
Pre-2020 I saw pull requests as blockers. The happy path for code to production was co-authored commits pushed straight to master and continuously deployed to production. The sad path was for it to wait in a pull request to get reviewed. Now I see PRs as the path to optimise for. It’s slower, but more consistent.
