If you smelt...you dealt it

No this entry is NOT about flatulence.  Ironically, there is a Wikipedia page that is - here.  Instead my intent is to opine on the practice at my employer about developers supporting their own code - which means that if you broke something then you are going to be the one to fix it.

When I was managing the production support team at my previous employer; the team's responsibility was to focus on the operation of key systems and ensure that they were available and meeting SLAs.  This team did a good job at keeping things moving - if something broke they got to be pretty adept at fixing issues.  If you look at this as an outcome with a fixed cost (which is how we structured it) then it can look pretty attractive.  But in the end the people on the team had many concerns/issues/complaints/etc about the challenges they faced in sustaining this model.  In the end - I feel that this model takes too short of a view of life cycle of a system and therefore is flawed.

First it is worth noting that Amazon has a list of core leadership principles that they live and breath by.  I have done a lot of chin rubbing around these as of late and the more that I play with them the more I like them.  When considering this post there were a few in particular that I felt applied..."Ownership", "Invent and Simplify" and "Insist on the Highest Standards".  If you read the short descriptions for each of these they are all pointing to how separating support from development is flawed.

If developers are not responsible for keeping their own code running or seeing how it behaves in production then how they doing any of these things?  Sure it is possible that you get outcomes in this direction; but it is not likely - especially without the ownership.

A related topic to this is how we work this into our Agile methodology to ensure that we still get things done on time.

Firehose Treatment - Open Wide

I needed to take a short bit of time off from blogging while I worked out the details of interviewing, negotiating and relocating (at least me) to Seattle from Connecticut.  I am now into my second week of work at the largest online retailer and the fire hose is blasting full force.

Being this big means that someone has already done a lot of thinking about how to make something massively scalable.  Back in "the day" I remember pouring over the Principles of Transaction Programming book by Phil Bernstein.  I knew this stuff inside and out and it still serves me.

 

Given the massive need for scalability I have had to dust of some new/old theories. ACID is out BASE is in.  Sure I have read about a bunch of these over the last few years, but it is different being at a place that is actually doing it.

Here is a list of things blowing my mind today...

1. Eventual Consistency - It will get there when it gets there.


2. Anti Entropy - Anything with the word entropy in it I find confusing.  So what is Anti-Entropy? :-0


3. AWS - I had to pay for this before, now everything we deploy is already running on this.  Note to self; shutdown my services and save a couple bucks.