Augie Fackler, Nathaniel Manista - Stop Sucking Me Into Your Drama: A Personal Appeal For Loose Coupling

Great software is made out of cooperating independent modules; unusable, incorrect, and bad software happen when modules don’t (or can’t) work together. What makes modules friendly or hostile? How do abusive relationships between modules happen? How can we write code that creates and maintains healthy connections to other code?

https://us.pycon.org/2015/schedule/presentation/381/

Transcript

1. Augie is a contributor to Mercurial and various Python libraries. Nathaniel has contributed to Pylint, Melange, and gRPC. Stop Sucking Me Into Your Drama A Personal Appeal for Loose Coupling Augie Fackler & Nathaniel Manista Google, Inc. 10 April 2015 Stop Sucking Me Into Your Drama http://localhost:8080/print/ 1 of 34 4/10/15, 5:13 PM
2. We have many relationships in life. Most (hopefully!) of these are productive, but sometimes they're not. We choose to distance ourselves from harmful people, both professionally and personally. Relationships Stop Sucking Me Into Your Drama http://localhost:8080/print/ 2 of 34 4/10/15, 5:13 PM
3. We also have relationships with things. Sometimes those relationships are mostly positive (my swiss army knife has been around almost 20 years and I still get a lot of productive use out of it). Sometimes, things ask a lot of us. Happiest days in the life of a boat owner. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 3 of 34 4/10/15, 5:13 PM
4. There's a thread in modern culture that says to be skeptical of owning too much... The things you own end up owning you. — Fight Club Stop Sucking Me Into Your Drama http://localhost:8080/print/ 4 of 34 4/10/15, 5:13 PM
5. But in fact it's a very old idea. Owning high-maintenance things is not fun (except when it's a hobby or a pet.) This applies to software too! You have many relationships in software: some are social, but you also have a relationship with the inaminate object of the software itself. I've had many days where software has left me emotionally drained and mentally exhausted. The Master has no possessions. [...] The more she gives to others, the wealthier she is. — Tao Te Ching Stop Sucking Me Into Your Drama http://localhost:8080/print/ 5 of 34 4/10/15, 5:13 PM
6. Technology things not infrequently bring us their own curious drama. Opera, Nathaniel's social-media-containment-browser, wants to make changes. What changes? What is this going to get me into? Stop Sucking Me Into Your Drama http://localhost:8080/print/ 6 of 34 4/10/15, 5:13 PM
7. Back in 2008, Augie tried to use Linux as a daily driver, but it didn't work out, mostly because audio kept breaking due to PulseAudio. This got better, but that was the last time he tried to go linux-only for my personal computing. PulseAudio in 2008 Stop Sucking Me Into Your Drama http://localhost:8080/print/ 7 of 34 4/10/15, 5:13 PM
8. Politically, we support causes without campaigning for them. Socially, we avoid getting involved in conflicts between friends. Professionally, we sometimes file a bug and move on without fixing a problem right now. As consumers, we are wary of recurring fees and lock-in. How can we defend ourselves from (software) drama? Stop Sucking Me Into Your Drama http://localhost:8080/print/ 8 of 34 4/10/15, 5:13 PM
9. Everything here feels like common sense, but everyone here (including us) violates these principles regularly. Sometimes it's out of expediency, but often we don't clean up later and it becomes a burden. LOOSE COUPLING Stop Sucking Me Into Your Drama http://localhost:8080/print/ 9 of 34 4/10/15, 5:13 PM
10. How can we do better? Stop Sucking Me Into Your Drama http://localhost:8080/print/ 10 of 34 4/10/15, 5:13 PM
11. A few guidelines for using an API that you don't control; possibly one that wants to suck you into its drama. When behaving as a client Stop Sucking Me Into Your Drama http://localhost:8080/print/ 11 of 34 4/10/15, 5:13 PM
12. Pretend not to know how your dependencies are implemented. Pretend not to know what's really going on under the hood. Pretend not to have looked at your dependencies' source code. Build your system relying only on what your dependencies have actually guaranteed, in writing, in their public API. Consider using less than the entire public API available to you. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 12 of 34 4/10/15, 5:13 PM
13. Compare dependencies and pick low-drama ones. Evaluate service providers and libraries in similar ways. Use as little as needed from a dependency, or avoid dep entirely if drama outweighs benefits. Also evaluate the difference between services and libraries. Services can vanish without warning, libraries are slightly harder to lose access to entirely. Prudence in dependencies. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 13 of 34 4/10/15, 5:13 PM
14. Scaling is really really hard. If you end up on the front page of $MAJOR_NEWS_OUTLET, you don't really want to have painted yourself into a sharding corner, do you? Spending a few minutes today thinking about the future might save you lots of pain later. On the other hand, using a NoSQL datastore for the prototype is likely subjecting yourself to pain you don't need. Just because today's database lets you do global transactions doesn't mean tomorow's will. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 14 of 34 4/10/15, 5:13 PM
15. The Chernobyl Design Pattern: taking a poisonous dependency that for some reason you have to use and wrapping it in a sarcophagus that contains the damage. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 15 of 34 4/10/15, 5:13 PM
16. A few guidelines for creating an API that you want to have healthy relationships with those using it. When providing an API: Stop Sucking Me Into Your Drama http://localhost:8080/print/ 16 of 34 4/10/15, 5:13 PM
17. Step away from everything you learned from having built your system and imagine yourself in the place of someone _using_ your system. What do you want them to have to know? What do you want their experience to be? Empathize! Stop Sucking Me Into Your Drama http://localhost:8080/print/ 17 of 34 4/10/15, 5:13 PM
18. Don't allow yourself to say "everybody knows". Our profession is expanding and welcoming a lot of people who didn't grow up programming - and that's a good thing. It's no longer safe to assume that everyone who wants to use your system will know the POSIX API, or the standard set of Unix command-line tools, or filesystem semantics, or database queries, or even TCP and HTTP. That's a good thing! Stop Sucking Me Into Your Drama http://localhost:8080/print/ 18 of 34 4/10/15, 5:13 PM
19. Just this week we both learned about a feature of TCP which, when combined with an OS X feature, led to a potential DoS attack on apps using the network. Surprise! https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html TCP is Crazy (CVE-2015-1105) Stop Sucking Me Into Your Drama http://localhost:8080/print/ 19 of 34 4/10/15, 5:13 PM
20. Continuum on which to place your system. "Utilities" exist in the context of the other systems on which they depend. "Solutions" encapsulate their dependencies and export a new universe of ideas to their users. Your (System's) Identity Crisis "Utility" or "Solution"? "Transparent" or "Encapsulating"? Stop Sucking Me Into Your Drama http://localhost:8080/print/ 20 of 34 4/10/15, 5:13 PM
21. Codewalks and examples help your users build one specific thing or a few specific things that you are able to imagine beforehand. Inventories, that simply list what parts your system delivers and how they interoperate, better help your users build any arbitrary thing they can, including things of which you haven't imagined. Provide both inventories and codewalks. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 21 of 34 4/10/15, 5:13 PM
22. It may be unavoidable that you expose limited-lifetime objects in your API. Avoid inappropriate exposure of life-cycle management. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 22 of 34 4/10/15, 5:13 PM
23. Everyone in this room is more-or-less fully constructed; most of us have these useless leftover artifacts of how we were built. What does that look like in software? Stop Sucking Me Into Your Drama http://localhost:8080/print/ 23 of 34 4/10/15, 5:13 PM
24. These kinds of methods are a problem because they then hang around available to be mistakenly called later. Context managers and the with statement are great; use them. def initialize(self, lifecycle_argument): """Must be called exactly once. Must be called before any other method. """ # <some implementation> Stop Sucking Me Into Your Drama http://localhost:8080/print/ 24 of 34 4/10/15, 5:13 PM
25. It's *generally* the case that import-time side effects set up some global shared state that ends up limiting potential uses of your software. If there's some set-up that you think needs to be performed, expose a way for your users to invoke it as a context object of some kind. Don't "magically" "help" them. Avoid side-effects on import. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 25 of 34 4/10/15, 5:13 PM
26. We want to construct separated, mutually insulated failure domains that distrust one another. Message-passing across boundaries. Doesn't have to be asynchronous. Reactive systems help ensure loose coupling. This means if you fail to load some data from a server, you degrade gracefully. Sometimes gracefully means showing an error message, but often it means you just show less data overall. When assembling your system, establish internal boundaries of minimal trust. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 26 of 34 4/10/15, 5:13 PM
27. This all-in-one print/scan/fax had some pretty poor coupling: when the print mechanism broke during a cross-country move, the device became unable to scan. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 27 of 34 4/10/15, 5:13 PM
28. Mario wrote a test that passed for everyone when they ran it on their own, but that failed for all users except Mario when run on the shared reference machine. We scratched our heads for hours! Testem Javascript Tests for Melange Stop Sucking Me Into Your Drama http://localhost:8080/print/ 28 of 34 4/10/15, 5:13 PM
29. This prevents multiple users in the same system to run tests. The first user would run tests, which create directories like /tmp/testem.firefox which are not readable/writable by other users. Since those directories are not deleted after a run, if another user in the same system try to run tests they will be stuck. A patch for this is on its way :) .notes For those of you who don't like walls of text, the story here was... github.com/airportyh/testem/issues/284 Currently testem creates temporary profiles in fixed directories in the system's tmp. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 29 of 34 4/10/15, 5:13 PM
30. When guarding against drama be sure to guard against crazy as well as simple failure. youtrack.jetbrains.com/issue/IDEA-11744 IDEA behaves poorly if cvs server behaves poorly Attempting to do a "compare to same repository version" on a source file caused IDEA to lock up for about thirty seconds and then present me with my cvs settings. Stop Sucking Me Into Your Drama http://localhost:8080/print/ 30 of 34 4/10/15, 5:13 PM
31. Good Examples Stop Sucking Me Into Your Drama http://localhost:8080/print/ 31 of 34 4/10/15, 5:13 PM
32. Django Separable components - throw out the templates, or the ORM, but keep the rest Stop Sucking Me Into Your Drama http://localhost:8080/print/ 32 of 34 4/10/15, 5:13 PM
33. WebDriver makes driving different browsers consistent across browsers Stop Sucking Me Into Your Drama http://localhost:8080/print/ 33 of 34 4/10/15, 5:13 PM
34. Thank you! Stop Sucking Me Into Your Drama http://localhost:8080/print/ 34 of 34 4/10/15, 5:13 PM