How can we defend ourselves from (software) drama?
When behaving as a client
Deliberate ignorance
- don't worry about how the thing works
- just use it according to its public API
- forget your internal knowledge; request
Be prudent in your dependencies
- evaluate all your options
- don't just pick the first one or the oldest one
- how well documented is the library?
- are there API guarantees?
Don't necessarily use a dependency's entire feature set, especially if it's got obscure features
- Just because today's database lets you do global tansactions doesn't mean tmorrows will
When providing an API
Empathize!
- put yourself if your user's place
- what should they need to know to work with your system?
- users want to come in, pick up your library, use it, and forget about it
Question yourself anytime you say "everybody knows"
- who knows assembler anymore? TCP?
Your system's identity crisis
- is it a "utility" or a "solution"?
- is it "transparent" or "encapsulating"?
Don't make your users have to become domain experts in your domain and related domains
Provide both inventories and codewalks (reference vs. narrative documentation)
- inventory: listing of all functions and things
- codewalks: specific examples of building specific things with your system
Avoid inappropriate exposure of lifecycle management
- for example, forcing users to call initialize() after cronstructing an object
Avoid side-effects on import
When assembling your system, establish internal boundaries on minimal trust
- if something fails, limit the effects to that part of the system
- network is a natural place to draw such boundaries
Good Examples
Django
- don't have to use everything
- can throw out the ORM or the template system
WebDriver
- using Firefox is the same as using Chrome or phantomjs, etc.