If you smelt…you dealt it

nofartNo 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.

amazonlogoFirst it is worth noting that Amazon has a list of core leadership principles that they live and breath.  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.

Agile Musing

I was at a LOMA meeting for work last week and was talking to a couple of other attendees about their Agile practices.


It reminded me of some early thinking I was doing back in the 90′s.  I was always drawn to doing things in what people now call an Agile way; but the first time I heard someone actually put words to what I was thinking was a presentation Jim McCarthy did at the 1995 Microsoft Global Summit in San Diego (I think).  I used to have the video on tape but it seems to be long lost at this point.  I found a couple YouTube excerpts but not the who thing.  He went on to write his book Dynamics of Software Development which elaborated on his 21 rules (I think the book has 40 something).  I remember liking his style…oh yeah…and the content was good too. :-)

The Pragmatic Programmer is another book that put more meat on the bones of things that I was thinking or struggling with.  I consider this a timeless book unlike the Peter Norton’s Programming Guide to PC book (the pink shirt book) I recently came across in my archive.Norton

As I reminisce I am reminded about the Agile Manifesto which at first made me laugh but after that tickling feeling passed I took the simplicity and truth of it to heart.  I attached the image I keep on my desk here for posterity.


Not sure what the next Agile is going to be.  I do feel like there is something still missing that  I can’t quite put my finger on.  Hmmm.