Tooling That JustWorks™

-
Google has a paper on how they’ve integrated Static Analysis into their development workflow, and managed to get it adopted by their developers.
Yup. “Adopted”, and enthusiastically at that.
How can that be? Especially when the tooling developers use is the cause of so much drama (vi vs emacs 🙄).
The thing to remember is that it’s not just irrational behavior though. We tend to perceive our tools as extensions of ourselves, and any perceived attack on the tooling is , by extension, and attack on our core being. When you add in risk-aversion, changes to tools are very likely to trigger a fight or flight response. Conversely, getting the tooling right, and getting it adopted, can have a ludicrously outsize impact on your products.
So what makes for good tooling? To summarize Google’s paper, good tooling must
  1. Be In Flow: Tooling must be integrated into the workflow, and harmoniously at that. Friction is the mind-killer
  2. Be Enabled By Default: Right out of Nudge, it is way easier to get people to do the right thing if it is the default. If they have to go out of their way to configure stuff, they either won’t, or will complain about it (and virtually everything else)
  3. Deliver Value: Even #CowboyDevelopers love things that generate real value. If you can show that the tooling will make their life easier, they willuse it. (And if they don’t, they are the problem, not the tooling)
  4. Always Work: Not “mostly”. Always. An easy metric here is looking at the time spent on edge-cases. If it is anything more than de minimus, the tooling needs work (or the code-base!)
  5. Shift Focus: The tooling should never be the focus. Heck, it should, largely, not even be visible other than peripheral/background activity. Instead, the developer should — always! — be focused on the problem at hand.
The last point — that the tooling should never be the focus — is in many ways the most important one. The tricky part here though is that developers are not all stamped out of the same mold, with each of them having their own efficiencies, foibles, and needs. Trying to accommodate everyone usually results in either a “lowest common denominator” solution (ugh), or worse, a swiss-army knife that looks nifty, but is actually not particularly good at anything.
The good news is that if you’re tooling meets the first four points, then if you introduce it early enough in the developer’s tenure, it can work wonders. New hires — no matter how experienced they are — initially focus on figuring out the lay of the land, on identifying the systems and processes they will deal with, and on “fitting in”. What can be perceived as a threat for existing developers, (changes can trigger a “fight or flight” response in most people!), is just “the way it is” for new hires.
This can be used as an effective technique to introduce tooling to teams. New hires, and/or junior developers are more likely to accept it, and rapidly gain expertise. This can serve as Adoption-Motivation for the more senior existing developers, especially when combined with additional care/feeding (extra training, coaxing, bribing, whatever). After all, nobody likes being upstaged by the new hire 😀.

Comments

Post a Comment

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

-
Image
The nice thing about garbage-collection is that it is makes memory management absolutely transparent to you Of course, the above is true right up to the point when it stops being transparent, at which point it does a phase change from nice to clusterf**k of biblical proportions .  There are entire posts, books, and suicide notes that have been written about this, and I have no great desire to add to them, save with the minor comment that paranoia about garbage-collection is still justified , albeit only in the edge-cases for most people. That said, I'll give you that Erlang GC is in many ways much, much better positioned in this regard than, oh, Java, but it still rears up and bites you in the butt when you least expect it. ( More information about Erlang's GC vis-a-vis Java here , and Jesper's truly excellent description of Erlang's GC here ).  A story from the past should serve to illustrate this. Once upon a time, in a magical land far far away - well, Her...
Read more

Spot The Difference — Deep Learning Edition

-
Image
You’ve played  Spot The Difference  at some point, right? (Of course you did. We  all  did  ). Think about what you actually did when you were trying to Spot The Difference — in fact, just do it again with SpongeBob juggling above. You’re probably doing something like 1. Quick glance to the left. 2. Quick glance to the right 3. “ Spatula on the left. Wonder if there is one on the right? ” 4. “ Yup, there is. Sriracha on the right. Is that on the left? ” 5. “ Nope! It’s a ketchup bottle on the left! And there is nothing on the plate below it! ” etc. To summarize, what you’re basically doing is looking at each image alternately, identifying objects in each image, and trying to find the same object in the other image. As it turns out, what most Deep Learning systems do is something quite different. They basically do something like this 1. Figure out everything in the first image (“ ketchup bottle at 1 o-clock, empty plate at 3 o-clock, spatula at 1...
Read more