Despite the crudeness of the phrase, I consume a lot of online content. The internet is awash in things to pass the time. Most of it is crap, the mental equivalent of cotton candy. However, there are a handful of talks that I continue to return to. They are the ones that, even after years, I highlight in presentations and compare and contrast with new information.
Here is a selection of some of my foundational references. Hopefully, you’ll find them as influential as I have.
How to Design a Good API and Why it Matters, by Joshua Bloch, Google Tech Talks (2007)
I’ve written some form of the Net API Notes Email Newsletter for the past several years. In that time, I’ve reviewed gobs of API-related content. However, I have yet to come across another piece which as powerfully states the importance of great API design, and what it is, like this video.
Joshua rightly argues that good API Design is:
- Easy to Learn
- Easy to Use, Even Without Supplemental Documentation
- Hard to Misuse
- Easy to Read and Maintain Code that Uses It
- Sufficiently Powerful to Satisfy Requirements
- Easy to Evolve
- Appropriate to the Audience
The kicker here is that Joshua isn’t even talking about web, or net, APIs. The APIs he is talking about are lower-level, intra-language interfaces. However, the fact that these things continue to apply to other contexts is a testament to the universality of the message.
How to Design a Good API and Why it Matters
Meeting Resistance and Moving Forward, by Linda Rising, GOTO Conference (2017)
Having lived (survived?) through several digital transformation efforts, each with various degrees of success, I have an appreciation for diffusion of innovation theory. The theory outlines “the process by which an innovation is communicated over time among the participants in a social system”.
Said another way, a disruptive change, like those brought about by digital transformation, is adopted by different audiences at different rates. Subsequent research has shown that any changing population breaks down into the same percentages:
- Innovators (2.5%): Will something for no other reason than it is new
- Early Adopters (13.5%): More discrete in their selections than innovators, adopters use status as early pioneers to maintain social credibility with their peer group while taking on less risk (cutting verses bleeding edge)
- Early Majority (34%): Willing to adopt innovations, but only after seeing what success with the innovation looks like among their peers
- Late Majority (34%): Are loath to adopt the innovation unless specifically told they have to, after which they require higher levels of support and encouragement
- Laggards (16%): Those who actively resist change, and will actively work to thwart an innovation for no other reason that it is new
Be warned: the opening five-ten minutes to Linda Rising’s talk is rambling and referential to the events at the time; many were still attempting to process the results of the 2016 presidential election. However, when you scrub past that, you get a wonderful insight into people’s relationship with technology. Any change agent attempting big things, at scale, needs this foundational awareness before developing their strategy.
Meeting Resistance and Moving Forward
Seeing Whole Systems, by Nicky Case, The Long Now Foundation (2017)
Software governance at enterprise scale is tricky. To explain reoccurring phenomenon, I had to expand my research beyond typical software fare. Donella H. Meadows “Thinking in Systems”, and related systems dynamics education, has been incredibly relevant.
The software environment in most companies is a complex, dynamic system. A defining characteristic of a complex system is that the behavior cannot be understood by knowing about the individual components. There is not a linear relationship between a top-down mandate and the desired outcome. A complex system will exhibit emergent behavior when nudged; behavior that is always unexpected, and sometimes undesirable.
It is one thing to realize you’re a participant in (or victim of?) a complex system. A logical next step is identifying what to do about it. Nicky Case’s video on Seeing Whole Systems goes into that detail. Nicky, correctly, articulates how too much of governance thinking presumes clear causality between actions and outcomes. This is the mentality of “something bad happened, so we’ll create a rule to prevent the bad thing from happening”. Instead of edicts or directives, Nicky demonstrates how virtuous feedback loops (either positive or negative) can work on a dynamic system over time.
Wrapping Up
That’s a brief, first list of references that I return to regularly. If folks find this useful or know of related material I should check out, let me know.
