collaborating

Relations and the benefits of coding to an interface

Interfaces are an awesome idea. It’s a tale that all programmers have come across. If you program to a protocol then everyone gets to say “Hey! I can speak that” and join in the fun. TCP/IP, HTTP, my api I created for Bookie. What’s interesting is that I don’t feel like it’s been completely bought into the operations side of the world. There’s a few I can think of off the top of my head; snmp, rrd, and I supposed prometheus is finding some popularity lately. It's one of the more powerful ideas built into Juju and I was hit over the head when doing my latest tinkering with Gitlab

In that blog post I used a new charm done by a member of the community that enables you to proxy anything that speaks the http interface and secure it with Let's Encrypt. At first I went "Cool, this means I can easily set this Gitlab up as https://code.bookie.io and be awesome.". Now that was true, but then I started thinking bigger. Wait a minute, we've got a ton of applications in the Juju Charm Store that all speak the http interface. So I went to work. I wanted to setup everything I might want for my open source project. A handful of juju deploy commands followed by a handful of juju relate commands and my org is up and running. I setup the follow project stack on GCE with JAAS

  • code hosting (Gitlab) - https://code.bookie.io
  • wiki (Mediawiki) - https://wiki.bookie.io
  • continuous testing (Jenkins) - https://ci.bookie.io
  • blog (Ghost) - https://blog.bookie.io
  • mailing lists (Mailman) - https://lists.bookie.io

What impressed me here is that with one simple chunk of work, the Tengu team enabled so many other applications to benefit. I suppose I'd seen this before with things like the HAProxy charm. It enables any of these applications to be placed and scaled behind HAProxy, but this one feels a bit easier to use and more use facing as it's providing that https endpoint with the clean DNS names. 

This is the type of idea that I feel like make Juju a much more interesting idea than other tools folks tend to compare it to. There's a lot of people writing Puppet modules, Chef cookbooks, or adding "one click deploy" features, but I don't see that there's this idea of standing on each other's work as built in as it is in Juju. I've worked in OpenSource a long time now and there's nothing better than finding folks that are smarter than you, and leveraging their brains in your own work. You can do this, but I find that the design that Juju has put together encourages that things are modular and solutions are stood up as a series of parts each doing their thing well in a very portable way. 

The http interface is really common, but you can imagine others that could be as impactful. I'd love to brainstorm with folks on what are some of the biggest bang for the buck ideas out there that enables sharing of the operational best practices across many software applications. I can think of a handful in monitoring, logging, and metrics. Let me know what you can think of @mitechie.

When others put your thoughts into clear words.

You have to love how when some people speak, everyone stops and listens. A shareholder letter from Jeff Bezos is making the rounds and I love how each of us reads the letter and internalizes it differently. We all find ways to relate our own world to different bits of the shared wisdom. 

Myself, there were two ideas that have been spinning in the back of my head lately that were put together in a really great way by Jeff Bezos. 

When user testing isn't the whole story

Good inventors and designers deeply understand their customer. They spend tremendous energy developing that intuition. They study and understand many anecdotes rather than only the averages you’ll find on surveys. They live with the design.
...
A remarkable customer experience starts with heart, intuition, curiosity, play, guts, taste. You won’t find any of it in a survey.
— https://www.sec.gov/Archives/edgar/data/1018724/000119312517120198/d373368dex991.htm

This is one that I've been working so hard to process. We're all focused on measuring and data and so we work hard to include user testing in the design process. It's 100% correct to measure and work to understand what actually happens out there in the real world.

Everything can't be a simple a/b test. I have seen and fought getting too carried away with doing what the testing says. It's so easy to let go of responsibility and respond "the user testing says ...". I think that user testing is great when you're looking for small tweaks and changes or general feedback on if something appears useful and interesting. If I want to improve the click through rate, rearranging the content, the design of call to action buttons, or even the information architecture all might help. NONE of these though are breakthrough ideas that provide something new and excited for users. They're not truly things that are part of the identity of a product.

I often find that in Juju users will nearly always provide feedback that's the shortest path from their task to having it work the way they want. It makes sense from where they're sitting. A user might request some fast path to making a quick change after a deployment in a one off way. Juju is built on a consistent model. Anything that's done that's not part of that model, the state, is lost for future decisions and understanding. We often find we need to take the user feedback and get into what they want to do in this "one off" and see where we have an opportunity to improve the model so that the user is able to leverage Juju but the model is still consistently the focus on the product. I feel like the key word I want to use here is intent. You can filter ideas, test results, and then put some true intent behind them to build something of value. 

Getting others to agree by allowing them to disagree

...use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
— https://www.sec.gov/Archives/edgar/data/1018724/000119312517120198/d373368dex991.htm

This is a lesson I first learned myself in code reviews. I'd see some code and completely hate it. However, if I stood back, I'd realize what I hated was that it's not "how I would have done it". I would have to watch myself and not be negative just because someone else thought differently.

I like how Bezos's letter makes disagreement a reason to get together. "but will you gamble with me?" is a really great way of putting that. I find that normally this is a lesson for myself. To make myself willing to gamble on someone else's work or ideas. I obviously am already sold when it's my work. 

Sometimes, in order to get folks on board, they just need permission to not be held accountable if it fails. In code review, your goal isn't to be perfect all the time. In decision making, some will be good and some will not work out. However, you need permission to let the team move forward on something and learn from the outcome. None of us will be right all the time. 

What do you find interesting or personally meaningful in the letter? Do any of the ideas really speak to something you've been noodling on in the back of your mind. Let me know. @mitechie