I’ve posted the slides to my talk on SlideShare but here are my highlights from the other speakers.
Gene Kim: The Unicorn Project and the Five Ideals
Architecture is a better predictor of performance than even Continuous Delivery.
Good architecture is measured by “lunch factor”: how many people do you need to take to lunch to get something done.
Larene Le Gassick: Full Stack Accessibility, and the Business Case for Inclusion
Referenced Microsoft’s Inclusive Design Toolkit which includes an interesting diagram distinguishing permanent vs temporary vs situational disability. The affected audience is much larger than just permanent disability.
Mandy Michael: Frictionless Frontends for Backend Developers
Emphasised the value (and relative ease) of building something simple from scratch rather than start with a bootstrap library that you eventually need to replace.
For me this was really just updating what is the state of play of Web frontend technology and resources including very recent (1 week old), new browser capabilities.
Some web sites referenced that I thought were neat:
Arty Starr: The Ultimate Metric
Human understanding is the limiting constraint in software development; friction in software development is the time to recover understanding.
She has a book called Idea Flow on Leanpub that expands on the idea.
Limiting constraint concept is from Theory of Constraints. Made me think about whether this was true given I’m wary of the entire idea of single limiting constraints. Reminded me of Allen Ward’s product development wastes in Lean Product and Process Development.
Rebecca Wirfs-Brock: Growing Your Personal Design Heuristics
Discussed understanding and cultivating your own personal design heuristics rather than just rely on others.
James Shore: Evolutionary Design Animated
Simple design, continuous design, reflective design.
It’s easier to add design that’s missing than it is to rip out design that’s wrong.
James Shore’s Rules for Simple Design:
- Every Concept Once
- … and Only Once (Don’t Repeat Yourself) [He prefers Once And Only Once (XP) over the Don’t Repeat Yourself (DRY, Pragmatic Programmers) because of being more clear that ensuring every concept is expressed is itself an important point.]
- Design intent clear and obvious
- Concrete, not speculative
- Cohesive: code that changes together, stays together
- Decoupled: if it’s out of sight, it’s safely out of mind
- Isolated: if it’s widely used, it’s abstracted by an interface
This is a nice summary of the design taste that was expressed on the Portland Pattern Repository (c2.com) in the late 1990s, early 2000s. More complicated than Kent Beck’s rules for simple design which I tend to default to.
He mentioned that evolutionary design is not applicable when dealing with code that you don’t control (i.e., across interface boundaries). I was surprised that he didn’t mention Conquer and Divide as a way to address this.
Ken Scambler: Grow Your Own Tech Leads
Essentially emphasised the importance of being predictable and reliable (aka “don’t be terrible”) and the positive impact this has on your boss and colleagues.
James Lewis: Scale, Microservices, and Flow
Mentioned the thing about how organisational productivity typically drops with scale while city productivity increases with scale. I was never clear how that insight translates to how we might design organisations or even if it does.
Erik Dörnenburg: Ready for Rust
Rust is the future of systems programming.
Hillel Wayne: Designing Distributed Systems with TLA+
I’ve been sceptical about the practicality of formal methods for a long time.
From what I can tell, TLA+ is running a simulation of a complex system to highlight points of failure which would otherwise be very difficult to detect, even with disciplined TDD and review.
Looks interesting enough to follow-up on.
He has a book: Practical TLA+
Simon Brown: The Lost Art of Software Design
His approach seems similar to how we typically approached the preliminary technical exploration in Inceptions at ThoughtWorks when I was still there.
I see the C4 diagrams as boundary objects to facilitate dialogue.
My thought is not that there’s some alternate world where web development is done in Scheme but rather that competitive dynamics meant a lot of the messiness was inevitable.
This feels like a variant of Worse is Better.
Sabine Hauert: Swarm Engineering Across Scales: From Robots to Nanomedicine
Instead of relying on expensive, intelligent robots, first send a dumb, cheap, random swarm cloud which leaves trails for a subsequent expensive, intelligent robot to follow.
Michael Hunger: How Graphs Help Investigative Journalists to Connect the Dots
Cat Swetel: 193 Easy Steps to DevOpsing Your Monolith
“Is anyone familiar with the Dads Pants Manifesto?”
DevOps is NOT just a mindset. [Same for most things]
Psychological safety is important but nowhere near sufficient to improve a sociotechnical system.