What do you call the people you write software for?

For most of my career I have referred to the people who I write software for “users”.  It just made sense, they are using the software so they are users?

Interestingly enough at Amazon we call them customers.  Not to say that the word user has been stricken entirely from the vocabulary, but it makes me wonder if it should.  Here is my thinking.  Something different happens in my mind when I think of the people I am writing software for when I use the word customer.  It is hard to describe…but maybe this story will help you understand what I mean…

When I worked at Microsoft I worked in the consulting division and we would help people make sense of the variety of ways to write code on the Windows platform.  Often times some of my customers (aka clients) would have come up with a unique way to solve a problem using some piece of Microsoft software.  When I would relate this back to the product team (another aspect of my job).  More times than not the question I would get back would be “why would they do that – that is not what we intended”.  We used to refer to this as the RDZ – reality distortion zone; which was the invisible field that hung over Redmond that prevented the product teams from understanding how people really used Microsoft product.

When I think about how a customer centric Microsoft would have been different – then the response back to me would have been something like “that is really cool, we never thought of that – how can we make it better”.

Try it.  It may just change the way you think about things.

Possibly the Most Useless Code Post

rejectNeed a quick and dirty way to take an element normal XML file and turn it into a CSV file.  I know I could create something from scratch, but was hoping for a jump start on this since I am in a big hurry.

So I find this post.

This person gives me the code to take XML and turn it into CSV for his/her XML only!  Geez how useless is that?

I guess it just bugs me because I have been doing lots of interview code reviews and if I saw this I would laugh and hit the DO NOT HIRE button for this person.  Which has actually happened.  Sigh.


More Quotes

This blog was started/named based on some funny quotes from people I know.

Here are some more that we put on the board of honor…

  • “Please adjust your tone”
  • “Why not be paranoid”
  • “Maybe you should try unit testing”
  • “Please fix your software”
  • “Please fix your process”
  • “If all our assumptions are good, then we are good”
  • “It works on my machine”
  • “It’s a gift from the Security Team”


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.

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 bernsteinbookthinking about how to make something massively scalable.  Back in “the day” I remember pouring over the Principles of Transaction Programming book by 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.

Nasty Security Issue

Yesterday a colleague asked me to help with a security issue he was having.  He is someone who I consider to be a good developer; but does not have a good understanding of Windows security beyond the basics…Right click on folder -> Properties -> Security.

The problem manifested as this developer (only) loosing access  to a NAS share – “it used to work”.

First I confirmed that he was in the correct Active Directory (AD) groups and those groups had sufficient permissions to the folders in question.  Check.  Conclusion – it should work.

Then I had the developer write a quick web application to make sure he was passing his full credential to web server.  Check.  Conclusion – not something that is globally impacting authentication/authorization.  Seems to be something in the “conversation” between this workstation and the file server.

Hmmm.  Next thing was to try this from another workstation.  He remoted into a old Windows XP workstation.  It worked!!  Conclusion – something going on with his workstation.

Now I know that on my laptop, when I log into Windows but I am not connected to the network – I am using a cached credential on my workstation.  I also know that part of that credential is the groups that I am a member of.  So it seems that what this particular workstation is passing to the file server does not have the right groups since the server is denying the request.  Seems like there is something dirty/broken in the cache.

I typed “windows delete cached credential” into my favorite search engine and got this post.  We followed the steps that Ashok spells out…

  1. From Control Panel\All Control Panel Items\User Accounts click the username To the left you will see Manage your credentials.  From that select the share name and remove.
  2. Delete using net use Start > Run > cmd > net use * /DELETE

…and shazam…it worked.

There is a first for everything – this was definitely a first.

Now onto a nasty SharePoint issue that I have been putting off.   Hey at least I may end up with another blog post.


I was recently helping some colleagues think about interviewing techniques. I like to see work product from people. So a while back I developed an assessment that we use. It has been a big help in evaluating candidates.

When I worked at Microsoft we took our interviewing very seriously. Certainly there are lots of stories (myths?) out there about the process. Some truer than others. I have a master list of good questions and suggestions I still use from that time. It is helpful to review periodically to just get into the right mindset.

Along these lines…I was recently turned onto InterviewZen. I like the idea of being able to watch a recording of someone creating a work product. We have a classic computer science sort of problem (weighted graph) that I use, but I don’t get to see the person working thru their thinking. I am going to try and adapt mine to this format.

Powershell Quickee

As this title rolled off my fingers it made me laugh a little.

But hey, isn’t everything in PowerShell a little quicker?  At least that is the intent.  Over the past few years I keep dabbling in PowerShell from time to time.  I have just enough experience to know what can reasonably be done in the tool – without over extending it.  <soapbox> It looks like there are some people who take this tool and use it to bang every nail they have.  But that is another blog entry. </soapbox>

Here is the script I crufted up today for showing me all the services that are on a server set to run at startup (aka Automatic) and yet are NOT running now.

I was using the get-service cmdlet but it did not seem to be return the StartMode and State properties from a remote server (works locally fine).  So I Googled up an alternative that uses WMI.

foreach ($ServerName in $ServerList)
Get-WmiObject Win32_Service -ComputerName $ServerName |
Where-Object { $_.StartMode -eq ‘Auto’ -and $_.State -ne ‘Running’ } |
Format-Table -AutoSize @(
@{ Expression = ‘State’; Width = 9 }
@{ Expression = ‘StartMode’; Width = 9 }

Keep It Simple (kiss) Revisited

I have a calendar from a vendor we use that has some of the classic coding and design principles – one for each month.  I was rubbing my chin staring at it this morning and I wanted to share what popped into my head…

While I am sure that the KISS principle has been written about (perhaps to death) I had another instance of this today as it applies to operations and infrastructure.

Quick background – I recently inherited an Operational group.  Operations is the clean up crew of development here.  While I understand the rationale of separating them, I think I like the idea of developers supporting their own code so that they better understand the impact of what they do.  What a great teaching tool – you want to not get up in the middle of the night – fix the code, do a better job in the first place, write a utility to help you out.  We have a bunch of applications that have been around for years and over time the developers who maintain many of these have moved on.  So today I asked the question of someone about two AD groups and what they are used for.  In both cases the answer was initially I don’t know – and later the answer became these are not used anymore.

Part of keeping systems simple is getting rid of the things that are not used anymore.  We have all these extraneous moving parts that we don’t need.  This just creates system bloat that should be easy to remove.

Granted you cannot get to everything – right now.  But this stuff has to get cleaned up over time.  Putting it into some sort of maintenance, wish list or Kaizen log seems like an easy thing to do.

All it takes is discipline.

Yiddish for IT Leaders

I have come to the conclusion that I need to know more yiddish.  Can I use it as a code to hide what I am really thinking?  Help bypass any email filters?  Just make me feel better.  Here is my arsenal.

bupkis – As in – you don’t know bupkis.

chutzpah – There is always one team member with too much of this.

glitch – Things are late again?  It must be another glitch.

kibitz – What we should call reviews.

klutz – You don’t want this and a programming to go together.

kvetch – What I do when I get home from work.

nudnik – In management speak these are the team members you manage out.

schmuck – What you call someone who changes something directly in production – first.

schtik – A little off topic, but I think of Benji Bronk on the radio on my way into work.

shpiel – My weekly team briefings have at least one of these.

yutz – Yiddish has lots of fun words for describing people that bum you out.