The Developer is Dead, Long Live the Developer

I think it's perfectly reasonable for a developer to be aware of excessive memory fragmentation, leaking FD's, and anything else related to the process their program directs. It's well within my domain to debug such issues.

However the "devops" role is also pushing responsibility for configuring firewalls, LDAP ACLs, securing the OS, managing init daemons, and the entirety of the infrastructure on developers. Since it's all code now there can be more people involved and the silos can come down. "You build it, you run it," as you say.

What I'm suggesting is that for significantly sophisticated applications it won't be tenable to spread the responsibility on everyone. It's not reasonable to suggest that everyone be familiar with the implementation of a simulated-annealing algorithm in the continuous-domain constraint search solver. I think a support person would be well within reason to defer questions, bugs, and requests with that particular part to the developer responsible for it. And yet we're arguing that it's perfectly acceptable for that developer to be familiar with the intricacies of managing a data center of compute clusters? I don't know about you but I don't have an infinite amount of time on this Earth to take on such responsibilities.

I do think that there's a middle-ground to be exploited. If our expert system is ballooning in memory usage and crashing our servers it's reasonable for the developer to profile the memory usage under simulated loads and data sets and look for memory fragmentation or leaks, etc. I think it's a little too much to ask one person to also be intimately familiar with managing compute clusters, RAID failures, security policies, and package management. They, like many of us, may have a good, general idea of how it works but there exist specialists for a reason: it's hard to go beyond a certain degree of complexity without focusing. It's the reason why we work in teams!

1) Unit test. 95% of your test suite should be unit tests. Objects under test should not require the entire codebase to be loaded in order to perform... ideally they depend on nothing, or just 1 or 2 things (which in turn hopefully depend on nothing, or just 1 or 2 things, ad nauseum).

2) Don't mutate passed-in arguments. In fact, mutate as little as possible.

3) Don't use objects with potentially unexpected, surprising or unknown behavior that makes it difficult to reason around the code (QUICK- what happens when you merge a ruby HashWithIndifferentAccess with a regular hash containing both similarly-named symbol and string keys?)

4) Use function objects, that have zero side effects, wherever it makes sense. (Or just use an entirely functional language.)

5) Separate components that talk to each other through I/O should use something like the circuit-breaker pattern http://martinfowler.com/bliki/CircuitBreaker.html

6) Microbenchmark things. Individually, a series of tasks might all "look" fast, but when run 10000 times in a row, might expose unreasonable resource utilization.

It's another abstraction layer, and requires new skills.