If the kids are tired and grumpy, we might end up just seeing Lucy the elephant and the wolves. Other times, they’ve got tons of energy and we end up walking all the way to the end of the zoo to do the pony rides.

The weather also affects our experience. Rainy days can make it harder to enjoy rolling down the big grassy hill. And the snow definitely means that we can’t spend as much time visiting the outdoor exhibits.

Each of these variables can be tempered by food. Bringing snacks or buying food at the concession can help make the kids happier. Of course, taking the time to eat means slowing down the entire experience. But the extra time can also mean that the kids get tired and the cycle starts all over again. Some of my favourite times at the zoo have been on days when we’ve taken hours to go through all of the animals. Then again, some of the most difficult times have also been on days when we’ve been there for hours.

What I’m getting at is that there’s no way to know ahead of time what the kids will be like at the zoo. Despite doing my best to manage the variables, they always come up with ways to change the game. Even if they’ve had lots of sleep, the weather is perfect and I bring lots of food, there’s always situations that come up. Sammy might fall and skin his knee. Sara may choose to test her independence. Or maybe they both decide that they need to be bribed with ice cream.

While a plan is useful and sometimes followed, it’s useless for me to stubbornly stick to a plan in the face of toddler reality. Whether it’s called “rolling with the punches”, “taking it day by day” or simply “a day at the zoo”, the kids have taught me to be adaptable.

Herm Edwards, NFL Coach and ESPN football analyst, often talks about how quarterbacks deal with situations “when the train is delayed”. That is, the planned play has broken down and the quarterback has to improvise. Getting outside of containment, using his brain and his talent rather than blindly following a broken play, the quarterback that can make a play when the train is delayed gives his team more opportunities for success. While my kids don’t compare physically with 300 pound defensive linemen, my need to be adaptable with them is just as real.

So what does this all have to do with software development?

That’s easy – how many times have you been on a project when the train got delayed? Maybe your requirements changed. Or you didn’t know how to implement something technical. Or the budget got reduced. Or maybe it was something as simple as somebody screwing up. If your projects are anything like mine, the train gets delayed all the time no matter how good the plan is.

And that’s why it’s so important to be able to adapt. Whether you’re dealing with cranky kids at the zoo, 300 pound guys that want to squish you into the field or a project sponsor that continually changes her mind, you need to be able to adapt to be successful. And a rigid plan is not going to allow that.

Image credit: Leo Reynolds

Every company has a website these days, right? After all, websites are a relatively cheap way to extend your brand and make a lot of information available to potential customers.

And, of course, every website has a domain that goes along with it. Whether you’re bobslandscaping.com or joesgarage.ca, having a memorable domain is just as important as the website itself.

I had a conversation on Twitter last week about how unprofessional it looks when a company doesn’t use their domain for their email address. I’m always amazed when a company has invested the time and effort (not to mention the money) to create a website with a memorable domain yet they still continue to look like amateurs because they use a personal email address in their ads.

In the last week, I’ve seen ads in the paper where companies have used email addresses such as george@telus.net, sue@yahoo.com and frank@gmail.com. An email address is supposed to be part of your brand – why are you spending money advertising for telus.net, hotmail.com and gmail.com?

Furthermore, what happens if you decide to switch your internet hosting from TELUS to Rogers? Or if Yahoo! gets out of the email business? Your email address will change and you’ll have to notify all of your contacts of the switch. If you use your domain for your email address, then you get to choose your email address and you get to keep it as long as you pay for your domain.

The easy solution here is to configure your domain to use Google for email. Google offers free hosted email as part of their Google Apps offering. Not only is it free, but it comes with lots of benefits that can help your business.

It’s not difficult to point your existing domain at Google and get a free email address that actually uses your own domain. It’s easy to administer and you can always repoint your domain somewhere else if you end up leaving Google for some reason. Google has hosted email for my domain for the past 4 years and I certainly haven’t had any problems with it.

So, do you want to actually take advantage of your brand and the domain that you’ve already paid for? Good. Follow these (mostly) simple steps:

• Go to http://www.google.com/a/cpanel/domain/new
• Select “Administrator: I own or control this domain”.
• Enter your existing domain name.
• Click the Get Started button.
• Fill in the required information contact information. Be sure to place a check next to “I understand that if I cannot alter DNS records for my domain, I may impact my organization’s ability to use Google Apps”.
• Click the Continue button.
• Enter the username and password for the administrator account. This can be used as your email account if you wish or you could set up a separate “admin@domain.com” account – it’s up to you.
• Click the “I accept. Continue with set up” button.
• Congratulations! You’re now registered with Google Apps and should be logged into your Google Apps Dashboard.

That wasn’t so hard was it?

Now that you’ve registered with Google Apps, you need to prove to Google that you actually own your domain. After you’ve done that, you need to configure your domain to use Google for your email.

Here’s where I can’t help you much. The mechanics of managing your domain vary depending on how you bought your domain. You’ll need access to changing the CNAME and MX records of your domain. If you have access to this then you can simply follow the instructions that Google provides for you in the Google Apps Dashboard. If you don’t have access to configuring your domain, contact the company that you bought your domain from to get these configurations made. Most large companies like GoDaddy and EasyDNS give you access to your domain tools that make this configuration a cinch. If you need some help, feel free to contact me.

Registering your domain with Google Apps is a simple process that will allow you brand your email using the domain that you’ve already purchased. Take advantage of it and start looking professional!

Brian Donaldson from Quadrus was in town to present on the Quadrus Estimation Methodology. You can view Brian’s presentation on the Agile Edmonton site.

Most people expect software estimates to follow a Bell Curve, or Normal Distribution. That is, they expect the most common estimate (the mode) to match the average estimate (the mean). A Normal distribution implies that your actual progress is just as likely to be over your estimate as it is to be under.

Normal Distribution

However, Brian persuaded us that software estimates typically follow a LogNormal distribution. In a LogNormal distribution, the mode does not match the mean, which results in a skewed graph. For software development estimates, the mean is usually higher than the mode, which means that your actual progress is more likely to be over. This made sense to me when Brian pointed out that unexpected things in a project don’t often speed up an iteration (and even if they do the gains aren’t that significant) but they can often slow down a project (and the slowdown can be massive).

Lognormal Distribution

I’m getting to the “Ah-hah!” moment. But let me pull out the soapbox for a sec.

I’ve often been asked for a quick estimate to help get an idea of cost. The typical thing people say to make me comfortable with giving a high-level estimate is “just make it plus or minus 50%”. I’m sure you’ve been in that situation as well. This request always makes me laugh. For, you see, this type of hallway estimate is never based on anything close to a good understanding of the problem. That means that it’s pretty much a useless estimate that will probably come back to haunt me in the future. I have to laugh at this request because people look at you funny if you start to cry.

OK, enough soapbox and back to the point of this story.

Here’s the “Ah-hah!” – plus or minus 50% doesn’t exist. Assuming that your estimates do indeed follow a LogNormal distribution (and I’ve certainly seen that occur over and over again), minus 50% is nowhere near as likely as plus 50%. If anything, minus 10% might be as likely as plus 50%. Ah-hah!

So, next time somebody asks you for a “plus or minus 50%” estimate, you can feel free to explain the inaccuracy of their statement. Ask them if they’re willing to take a “plus 50% or minus 10%” estimate. Or, since they’ve already got a number in their head that is significantly lower than the number you’ve got in your head, just do what you’ve always done and pull a number out of your ass. Just try not to cry while you’re doing it.

Image credit: jespis

One thing that I really like about the Wordpress framework is that I can play around with it quite a bit despite the fact that I’m just learning PHP. The ease of customization was actually an unexpected bonus – I chose Wordpress because of the number of themes that are available for it. While I like playing with design, I’m not very good at it so it was a bonus for me that Wordpress has such a huge number of available themes.

And it’s not like I wanted to be too picky at this point. I was under pressure to hire a developer while we still had approval. I had already interviewed at least ten possible candidates and my recruiter was starting to give me that look. The look that says “I’m getting tired of trying to find developers that will never meet your standards.” I had seen it before but always had enough confidence to put it aside. But interview fatigue was taking its toll on me.

So, I pulled the trigger and hired Joe.

A few weeks later, I started to hear rumblings that Joe might not be working out. I was still suffering from interview fatigue, so I willfully ignored the whispers and forced myself to believe that Joe was just going through some new-job jitters and would turn it around over the next week.

But when one of the lead developers came up to me and said that Joe wasn’t working out, I couldn’t ignore it anymore. I sat down with Joe and asked him to walk me through some of the work that he was doing. Within a couple of minutes, it was obvious that he was in over his head and didn’t stand much of a chance of recovering.

At this point, I had two choices with Joe:

1. work with him for six months in hope of training him to the level that I expected him to already be, or
2. admit my mistake and fire him.

Despite the fact that I was burned out from interview fatigue and realizing that firing Joe would send me down a path of more interviews, I sat down with Joe and gave him his two weeks notice.

There’s a simple reason for this – if you allow somebody to keep their job when they’re not performing up to par then you are sending a direct message to the rest of your team that they don’t need to perform up to par either. As Jim Collins said in “Good to Great“, you need to have the right people on the bus but it’s also important to get the wrong people off the bus.

Having an undermanned team makes it difficult to meet aggressive deadlines. But having a fully-staffed team that doesn’t contain the right people won’t make it any easier to meet those deadlines. Even worse, refusing to fix a hiring mistake will damage your credibility with your team, eroding the trust that every team needs in order to produce outstanding results.

Dan Bergh’s take on the role of an architect sounds refreshing:

So, at the bottom line: I will not enforce architecture. I will not help enforcing architecture. I think it is a bad idea to enforce architecture. I think that if you want to enforce architecture you are working in the wrong direction.

Interview Fatigue can manifest itself both as somnolence (decreased wakefulness) or just as a general decrease of attention, not necessarily including sleepiness. It may also be described as more or less decreased level of consciousness. In any case, this can be dangerous when performing tasks that require constant concentration, such as interviewing a billion candidates for one software developer position.

I have a reputation amongst recruiters for being very hard to please. Of course, I believe that this is totally unwarranted and simply put it down to the fact that most recruiters are too dependent on resume keyword scan and don’t even understand the industry that they’re paid to serve. But that’s a topic for another post.

I guess the reason that I’m hard to please is that I look for developers that have both attitude and talent. That’s not easy to find in an industry that is mostly populated by the stereotypical geek that still lives in his parent’s basement.

For me, it’s a source of pride that I’ve been able to build fantastic teams full of developers that could not only produce great results but could also have fun and work together as an actual team. That sort of thing is not easy to do, especially when you have recruiters constantly bombarding you with mediocre developers. With all of those so-so resumes and interview sheets in front of you, you start to think that those mediocre developers are actually representative of the market. Even worse, you start to second-guess yourself and contemplate lowering your standards. And just like that night where you had too many drinks at the bar, lowering your standards makes it easier for you to make a choice that you’ll regret.

But there’s hope. Here’s my 3-step system for coping with Interview Fatigue.

Work in Teams

Don’t do all of the interviews yourself. While you may already bring other folks (senior developers, architects, HR, etc.), chances are that you’re still running the interview. While you may be the one that makes the final choice on which candidate gets an offer, you don’t need to do all of the ground work too.

Create a standard list of interview questions (you can even get together with your team to create this) and work with your team so that they can perform interviews with you. Take the lead in a couple of interviews and then have a post-interview debrief with your co-interviewers so that they can take the lead on the next interviews.

Not only does this start to free you from being involved in every interview, it also starts to build leadership and confidence in your team.

Limit your Choices

The gut instinct when faced with a series of mediocre developers is to find more avenues into the market. Maybe picking up a couple more recruiters. Or placing an ad on Monster or Workopolis. However, this strategy is the exact opposite of what you should be doing.

Gaining greater access to the market will only inundate you with more mediocrity. The problem is that most recruiters, and definitely most career websites, don’t know how to filter the wheat from the chaff. They simply log resumes and forward them to clients. Rather than perform a valuable service of selecting appropriate candidates, they rely on you to perform that selection.

The strategy that has worked for me in this situation is to actually reduce the number of recruiters that I deal with and focus on building a relationship with them. Work with them to understand what you’re looking for. Come up with some pre-qualification questions that they can ask candidates so that you don’t have to. “Drinking from the firehose” is the number one cause of Interview Fatigue. It only makes sense that the way to combat this is to reduce the size of the hose.

Stay Gold

The lower standards that come with Interview Fatigue can cause you to undermine your team with bad choices. Remember that you’re not just trying to build a team – you’re trying to build a great team. A team that is made of the top 10% of the market. That takes time and discipline. Find ways to remind yourself of that. Reiterate it in your meetings with your team. Find posters that are inspirational (but not too cheesy) and put them up. Make sure that everyone you work with knows your goal is to build the best team in town. Your words will be reflected back to you.

Thoughts?

Building a strong team of developers that have both attitude and talent is a difficult but extremely rewarding goal. I’ve found success following these pointers but I’m always willing to learn from the experiences of others. Share your thoughts in the comments.

The reason I’ve interviewed so many people is that I look for a developer with the right mix of attitude and talent. I want to work with people that have the drive to make themselves and those around them better. People that can create amazing software but also have the humility to realize that there’s still books full of things that they don’t know. People that have fun doing a geeky job that they also happen to do as a hobby.

Those people are incredibly hard to find. I’ve cut short interviews with lots of developers that had the right attitude but couldn’t explain basic programming techniques. But dealing with these poor developers isn’t as hard as struggling to maintain conversations with developers that were technically gifted but had no drive or personality.

Over the years, I’ve come to realize that there aren’t enough of these “Renaissance developers” to staff all of the teams that I’ve needed to build. This scarcity has led to compromises. But that leads to the question of what is more valuable? Attitude or Talent?

When faced with huge questions like this, I like to reach out to legendary minds that have more wisdom and experience than I do. Enter Pat Quinn:

I’ve always been a believer that attitude is probably way more important than talent a lot of times…

Like Pat Quinn, I’ve chosen to place more value on attitude than talent. There still needs to be a good base of talent, but ultimately talent is easier to teach than attitude.

As a community… we are trying to get folks to embrace change and to embrace uncertainty. We’ve got to recognize that we might be asking folks to embrace more uncertainty that they can likely handle. The reality is simply that many folks would rather be wrong than be uncertain.

For many people transitioning to Agile, the focus on clarity in the short-term is a real deal-breaker. Some people just want to spend the time (and this is usually lots of time) to get a full picture. This work rarely provides something of value and usually just ends up being busywork that puts the project even further behind. I’m definitely not against taking the time to plan the goals of a project but there comes a point where planning needs to shift to doing and most projects are slow to make that transition.

I don’t know anything about the Real Options theory that Mike is talking about in this article but I’m always interested in tools that can help to soften the blow of Agile adoption.

From Getting Rich Slowly:

I used to feel that I deserved to have nice things, that I was entitled to have a new car and a big house and the latest gadgets. I wanted to have what my parents had — but I wanted it when I was 30 instead of 50. Because my expectations were high, I spent to meet them.

My high expectations led to lifestyle inflation: As I earned more, I spent more. But I wasn’t any happier.

Once I learned to embrace frugality, I found that I could not only be happy with what I already had — I could be happy with less.

And from Zen Habits:

See, the cause of our stress, anger and irritation is that things don’t go the way we like, the way we expect them to. Think of how many times this has been true for you.

And so the solution is simple: expect things to go wrong, expect things to be different than we hoped or planned, expect the unexpected to happen. And accept it.

This idea certainly resonates with me. I often find that the movies I enjoy the most are the ones that I had the least expectations from. Recent examples include Transformers: Revenge of the Fallen, The Hangover and RocknRolla.

Any other examples of finding increased happiness by lowering the bar?