A message to my fellow developers: I want my apostrophe back

On the web my last name is a blessing and a curse. The name itself isn't the problem, it's just how it's mutilated in the name of security

More often than not, when entering my last name into a web form, I receive a message that it's not valid because of the apostrophe.

It is a valid name, it's mine. It's O'Sullivan not OSullivan and I'm rather attached to it.

This isn't just limited to apostrophes, but certain other characters too. For example, a friend of mine has a space in his last name and experiences similar problems.

Yes I know that we should sanitize input to help prevent things like SQL injection attacks and cross-site scripting, but the former can be handled by not generating SQL with data baked right in. We can use placeholders or a full blown ORM to help prevent attacks. The latter with encoding data correctly.

You may think what's the big deal, but can you guarantee that you have all combinations of possible characters for last name validation? A simple a to z match isn't going to cut it.

One of the blessings about having an apostrophe in my name is that I learnt how to deal with them safely very early in my career.

Things have improved over the years though. My name used to break many an app, these days very few. If I do find one, this tells me that I shouldn't use their service.

My biggest problem with all this is usability. Earlier I mentioned telling the user that their name is invalid, but the bigger problem is with credit card processing.

Pretty much every site I've visited that asks for credit card info, asks for your name as it's written on the card. If you can't enter it exactly then it puts doubt in the mind of the user as to whether or not their transaction will succeed. There must be a reason why it has to be exact right?

So please can I have my apostrophe back. 

Who's with me?

Pet peeve of the day: the business

It really makes me cringe when people in IT or software development refer to those outside of those departments as 'the business'. It night seem innocuous, but there are certain things that this simple phrase implies.

1) IT and software development aren't part of the business, where the real work gets done.

2) it creates an us versus them culture.

3) if you refer to yourself as separate from the business, people will treat you that way.

It's amazing how a simple phrase can pack in so many meanings. Just remember that we are all part of the business.

Retrospective safety, we've got it backwards

When we talk about sprint retrospectives we talk about them as a safe place for team members to discuss their issues. This safety is normally from people external to the team, often management. This isn't what it's about, it's about having a safe environment to express your own personal views without fear no matter who is in the room.

Let's start with the normal suggested practice of safety from management. This is an anti-pattern. If your teams feel that they can't be open and honest then there's something seriously wrong and that needs to be worked on. Transparency and honesty are hallmarks of agile. Your agile coach, ScrumMaster or agile manager should protect the team from outside interference. If teams don't feel that they are protected from repercussions they won't be open and honest.

My previous company had two important values; say the hard things and hear the hard things. This went a long way to helping build a culture where honesty was tantamount. Did it happen all the time? No, but changing culture can take time.

It's all comes down to personal safety. That doesn't mean being closed off and hiding your feelings.  Quite the opposite, you should feel safe to share without repercussions. This can be especially important for team members who find it hard to discuss what's on their mind. This can be caused by a number of things. Confidence/self-doubt, fear of conflict, bad experiences, having one or more dominant people on the team amongst other things.

Setting up a place where being open and honest is required, helps create a safe environment for all team members to open up. It's not quite that easy though. You *need* have a dedicated facilitator who is neutral and impartial. The facilitator is there to make sure everyone's voice is heard and to navigate conflict. This helps build up confidence so that team members can share freely in the retrospective, eventually going as far as sharing issues at any time which is the ultimate goal.

Sharing issues never go away. Team members can revert to not sharing if the team goes back into a storming mode. That said, my own experience is that if you've done your job right, they still feel that the retrospective is a safe place. This is why it's so important to continue it as a practice even if teams feel they no longer need it.