During a training I was teaching recently we were talking about retrospectives and different ways to make them interesting. Afterwards one of the students came forward and suggested something interesting.
When you are working on services that need to scale to millions of users you typically come to the conclusion that you will never be able to start a debugger on one of your live services. Instead you need instrumentation (also known as logging, tracing or diagnostics) to make sure you can figure out what went wrong. What I see happening a lot is that developers start logging the raw HTTP request to capture all data. And there are several problems with this approach...
So when a web service is getting too much traffic it starts returning the 503 status code. Well written services also return the Retry-After header hinting the client when it should come back again. Good behaving clients then respect that or will back-off by themselves to make sure the server is not getting too much traffic. However this is not enough if there are bad behaving clients in the mix. And how do you identify the bad behaving clients?
Daily stand-ups. Either you love them or you don't. I have tried a lot of different times of day for it and a lot of people wonder what is the best time to do it? But before I answer that I have to remind you that daily stand-ups is the daily planning meeting for the team - not a reporting meeting.
I recently updated a bathroom in my house and being given my interest in agile software development and craftsmanship I always find it interesting to work with painters etc since they in theory are the role model for craftsmanship. While greatly impressed by the tile guy the painters surprised me with a new level of laziness.