I spoke about the importance of fast feedback across the software delivery pipeline at Developer Week 2017 on Tuesday. Below is the first 30m of the talk plus my slides which include links to my research.
For my presentation at AnDevCon SF 2016, I focused on how Espresso represents a fundamental change in how approach the process of shipping software that provably works on a mobile ecosystem that is constantly changing.
The feedback was overwhelmingly good, many people who stopped by the Perfecto booth before or after our talk came to me to discuss topics I raised. In other words, it did what I wanted, which was to provide value and strike up conversation about how to improve the Android UI testing process.
A few weeks back, Kin Lane (sup) emailed and asked if I could fill in a spot, talk about something that was not all corporate slides. After being declined two weeks before that and practically interrogating Mark Boyd when he graciously called me to tell me that my talk wasn’t accepted, I was like “haal no!” (in my head) as I wrote back “haal yes” because duh.
I don’t really know if it was apparent during, but I didn’t practice. Last year at APIStrat Chicago, I practiced my 15 minute talk for about three weeks before. At APIdays Mediterranea in May I used a fallback notebook and someone tweeted that using notes is bullshit. Touché, though some of us keep our instincts in check with self-deprecation and self-doubt. Point taken: don’t open your mouth unless you know something deep enough where you absolutely must share it.
I don’t use notes anymore. I live what I talk about. I talk about what I live. APIs.
I live with two crazy people and a superhuman. It’s kind of weird. My children are young and creative, my wife and I do whatever we can to feed them. So when some asshole single developer tries to tell me that they know more about how to build something amazing with their bare hands, I’m like “psh, please, do have kids?” (again, in my head).
Children are literally the only way our race carries on. You want to tell me how to carry on about APIs, let me see how much brain-power for API design nuance you have left after a toddler carries on in your left ear for over an hour.
My life is basically APIs + Kids + Philanthropy + Sleep.
That’s where my talk at APIstrat came from. Me. For those who don’t follow, imagine that you’ve committed to a long-term project for how to make everyone’s life a little easier by contributing good people to the world, people with hearts and minds at least slightly better than your own. Hi.
It was a testing and monitoring track, so for people coming to see bullet lists of the latest ways to ignore important characteristics and system behaviors that only come from working closely with a distributed system, it may have been disappointing. But based on the number of conversation afterwards, I don’t think that’s what happened for most of the audience. My message was:
Metrics <= implementation <= design <= team <= people
If you don’t get people right, you’re doomed to deal with overly complicated metrics from dysfunctional systems born of hasty design by scattered teams of ineffective people.
My one piece of advice: consider that each person you work with when designing things was also once a child, and like you, has developed their own form of learning. Learn from them, and they will learn from you.
The other day I was working on updating my visuals to describe the systems delivery lifecycle (SDLC) for software. Three new depictions arose.
Why does the SDLC need a better visual?
I’m doing this because I’ve never been afraid of change, and the visuals still in use today depicting the phases of delivery are disturbingly incorrect to the modern lifecycle. Take for instance a few common illustrations:
Waterfall, cyclical, even the dreaded CI eternity symbol, all crap as far as I’m concerned. The linear fallacy is just too much to bear.
So I got to work on the whiteboard, to play around with some ideas. I really tried to stick to the “design, build, test, deploy, manage, monitor” phase reductions to simplify my life before round 2 coffee.
Is the SDLC Just a Fractal?
The idea that even a man-made structure like wire transmissions* could elicit fractal patterns just like nature got me thinking about other man-made structures…software and processes…are there fractals in what we accomplish, despite our incredibly synthetic rules and predisposition for straight lines? I’ve always loved this painting:
Fractals have changed my thinking about perceived complexity as a result of a simpler algorithm. There are fractals in all of us, our heartbeat graphed out show how nature may just be surface complexity to our perceived reality.
So I drew out the ‘waterfall’ (yes, pun intended) like a Kanagawa painting:
So this works well for categorizing the levels of detail that a large-scale operation like rolling a new idea out into the market requires, but there’s no link to the continuous aspects of the process. Next.
How Is the SDLC Like Digital Public Transit?
After going back to the ‘wheel’ mentality, I realized that there are just some parts of the SDLC that don’t always connect to each other, or at least not every time you complete a full cycle. Things like ‘build’ in a TDD shop do not block ‘testing’, so forcing everyone to go through the ‘build’ phase is wrong.
If instead we were to write out each ‘phase’ of the SDLC in clockwise fashion in a circle, then draw directed vertices, we’d get something like a subway map, like this:
So that’s interesting, certainly more palatable than the fractal illustration for most people, and shows a bit of symmetry, even if just as a shallow concept. The thing I like the best about this one is that you begin to see logical byproducts result from visualizing the paths through this state diagram.
If you draw a line from right before ‘design’ until right after ‘test’, you’d see how the three design/build/test phases that traditionally developers would do and operations wouldn’t touch are separate from the deploy/manage/monitor phases, which mirrors how proficiency in either (but not both) roles usually decides which set of phases you’ll be spending most of your time on as a member of a ‘DevOps’ team, either primarily a developer or an operations person.
Does the SDLC Need Some Taoist Whoop-Ass?
Then things got really weird. I realized that the closer each of the phases are depicted to one another, the easier it was for me to keep in mind that it was possible (sometimes fortuitous) to jump from phase to phase as organically happens in real DevOps / agile teams.
Instead of putting the elaborations (curls, paths) on the outside of the continuous structure (circle), they should be inside it. At first I drew it like a ’69’ which I later remembered has cultural connotations that are best avoided. Flipping it around, only later when I was out to coffee with some co-workers did someone point out that it looks like the Taoist Taijitu (paisley) symbol. That endeared it to me further:
Any time I can work in some pseudo-science or eastern philosophy into a technical topic, the added mystical sense is a bonus as far as I’m concerned. You come off looking all cool and a bit nuts at the same time.
Further Detail on Why I Don’t Like Existing SDLC Paradigms
Formally, my problems with established paradigms for how to visualize the SDLC are:
The left-to-right approach as a one-direction trip is inaccurate to how effective people work together, not separate; there are loopbacks thanks to humans
The ‘fix’ to take a waterfall process and just wrap it around on itself to make a continuous process just seems lazy and incomplete
Most depictions have no symmetry and no emergence of ‘DevOps’ role separation
People will use what makes sense to them. I will continue to elaborate these ideas until they bore me.