Sideline

Backing up MySQL using Rake

2010-11-07

I was recently looking for a nice way to back up MySQL on our staging server. A Google search brings up a bunch of different ways but I ended up going with some code from the data_sync plugin on GitHub.

In particular, I ended up creating this Rake task:

namespace :db do
  desc "Dump the current database to a MySQL file"
  task :database_dump => :environment do
    databases = YAML::load(File.open(Rails.root.join('config', 'database.yml')))
    timestamp = Time.now.utc.strftime("%Y%m%d%H%M%S")
    sql_path = "#{Rails.env}_#{timestamp}.sql"
    tar_path = "#{Rails.env}_#{timestamp}.tar.bz2"

    case databases[Rails.env]["adapter"]
      when 'mysql'
        ActiveRecord::Base.establish_connection(databases[Rails.env])

        commands = []

        mysql_dump_command = []
        mysql_dump_command << "mysqldump"
        if databases[Rails.env]["host"].present?
          mysql_dump_command << "-h #{databases[Rails.env]["host"]}"
        else
          mysql_dump_command << "-h localhost"
        end
        mysql_dump_command << "-u #{databases[Rails.env]["username"]}"
        if databases[Rails.env]["password"].present?
          mysql_dump_command << "-p#{databases[Rails.env]["password"]}"
        end
        mysql_dump_command << "#{databases[Rails.env]["database"]}"
        mysql_dump_command << " > #{Rails.root.join('db', sql_path)}"

        commands << mysql_dump_command.join(' ')
        commands << "cd #{Rails.root.join('db')}"
        commands << "tar -cjf #{Rails.root.join('db', tar_path)} #{sql_path}"
        commands << "rm -fr #{Rails.root.join('db', sql_path)}"

        `#{commands.join(' && ')}`

        puts "Dumped #{tar_path}"
      else
        raise "Task doesn't work with '#{databases[Rails.env]['adapter']}'"
    end
  end
end

Running this task will created a compressed and timestamped MySQL backup in the db folder of your Rails app. What's nice is that this task is easy to wire into your Capistrano deployment.

desc "Export the database into the db/ folder"
task :dump, :except => { :no_release => true } do
  run "cd #{current_path}; rake RAILS_ENV=#{stage} db:database_dump"
end

Even better, you can call the dump task before running any of your other db-related cap tasks.

desc "Run pending migrations on already deployed code"
task :migrate, :except => { :no_release => true } do
  dump
  run "cd #{current_path}; rake RAILS_ENV=#{stage} db:migrate"
end

I've found this to be a nice simple solution.

Make Your Developers More Productive in 2 Easy Steps

2010-06-02

Let's just cut to the chase here: your developers aren't as productive as you (or they) would like because they are working on too many things at the same time and they don't always choose the right things to work on. It's often that simple.

One of my favourite lines to use is "if it hurts when you do that, stop doing that." Unfortunately, many software teams (and companies) don't follow this common sense advice. During the last year, I've started working with a couple of clients that both suffer from the same affliction: the devs can't finish anything.

The solution to this is actually pretty easy:

Allow your developers to only work on one thing at a time
Make it easy for your developers to know what they should work on next

Seems pretty simple, right? In fact, it seems simple enough that everyone should be doing it. But here's the problem - almost nobody is.

Getting Serious

2010-04-19

Up until recently, I hosted sideline.ca on Dreamhost using Wordpress. While Wordpress has been good, I've been feeling the need to use a simpler solution. Throw in my desire to move my hosting to something more Rails-friendly and it became obvious that I needed to leave Wordpress.

While Dreamhost has been cheap (less than $10/month), I wanted to do better in terms of cost. Something closer to...free. Amazingly, I had a number of options:

GitHub Pages - I like the simplicity of maintaining my pages in a git repository as markdown files. But you need to be a premium member in order to point your domain at your pages. In addition, I'll be moving another Wordpress instance off of Dreamhost so it would start to get clunky to maintain two different domains here.
Codaset Pages - Looks to be the same idea as Github Pages. Again, I would need to create a second user to maintain a different blog.
Google Sites - I've got a couple of domains using Google Apps so I could always use Google Sites. It solves the problem of needing multiple domains but I'm not a fan of having to hardcode a blog as static HTML.
Heroku - Free hosting for ruby-based apps with the ability to point my domain for free. Sounds like a winner!

With the platform decision made, I had a large choice of blog applications. I didn't want anything too heavy but still found a number of options:

Jekyll - Used for both GitHub Pages and Codaset Pages, Jekyll generates static HTML from a number of files that are combinations of YAML and Markdown. While generating static HTML means that you can post the files pretty much anywhere, I wanted to stick with an app that served out the content.
Toto - Toto also uses a YAML/Markdown mix in its articles. It's wired up to use git and Heroku extensively, which means that deploying a new article is as simple as git push. But after using it for a bit, I ran into some issues trying to break my layout files out into smaller subfiles (i.e. something like rails partials).
Serious - Serious is "inspired by toto and driven by sinatra". Again, it used YAML/Markdown for articles but replaced toto's custom framework with sinatra. After a bit of playing, I decided to go with Serious.

The key for me with Jekyll, Toto and Serious is that they all forgo storing articles in a database. Instead, they store articles as markdown files in the filesystem. This change alone makes for a fast site. Add in the caching of Heroku and you get a site that absolutely flies.

The only difficulty with losing a database is that you have nowhere to store comments. Enter Disqus - a 3rd party service that not only will collect and display your comments but will also filter spam and collect references to your posts on Twitter.

I made the decision to go with Serious and Heroku a couple of weeks ago. After extracting my articles out of Wordpress on Dreamhost, I had to spend quite a bit of time going through and cleaning up some of the links and URL's. In addition, any images that I had used in Wordpress had to be re-referenced. But I finally launched my site last week and couldn't be happier! The workflow of using Markdown and git for writing articles is really intuitive. In addition, Heroku has been a fantastic free host for the site.

If you're interested in seeing any of the code behind the site, or the articles themselves, I host it all on my Github account at http://github.com/mm53bar/sideline-ca. I've made a few changes to the Serious gem which you can find in the vendor directory.

An easy way to keep your developers productive

2010-04-17

Software developers are a tricky group. They're smart folks with lots of education. They're typically highly motivated to do a good job. These are the kinds of folks who have a blurry line between job and hobby.

But they will kill you as a project manager. Slowly.

Don't believe me? Try getting a developer to commit to a deadline. Assuming that you can get the commitment in the first place, the developer will typically disappear for quite a while. This is called going black.

Then, miraculously, they'll pop up just before the deadline with a variety of reasons for not being done.

They've been working on Bug X or Defect Y and haven't been able to do your work yet, or
The feature turned out to be a lot more complicated than they originally thought, or
They're assigned to more than one project and spent their time working on the other project.

No matter the reason, the bottom line is that the feature isn't done. And the deadline is looming. This is the game.

The Game

I've been a developer. I've played this game without realizing it. I'm not really sure why this game occurs. After all, nobody wins. Maybe it's because estimating is so damn hard. Or possibly the developers don't control the environment that they're coding in. Regardless of the reason, the game exists.

But, like water flowing downhill and encountering a boulder, the key is to come up with a way to keep moving forward.

What you need to realize is that the developers are not trying to screw you. You just need to know a simple rule about developers: the longer a developer is allowed to work on a feature, the less likely it is that they'll be able to deliver it.

Which leads to the simplest possible way keep your developers productive: talk to them!

Talk To Your Developers

Every morning, meet with your developers as a group. Have each of them talk about what they're working on that day and any hurdles that they're facing. The hurdles are your job to resolve. The developers are there to code. You're there to make sure that they can do their job.

In agile circles, this meeting is called a stand-up. Even if you're not trying to adopt any agile methods, adopting a ritual of daily communication is your way to stay in the loop on what they're doing. But remember that you're not there to micro-manage them. You're there to ensure that they commit to work and then you're there the next day to follow up on how the work went. Think of it as a series of micro-projects.

By maximizing your communication, you minimize your risk.

There's Nothing Like Face-to-Face Chats

One final tip - resist the urge to automate this process through some type of daily email or other remote check in. It won't work. You want more communication; not less. And the best way to get communication is to, well, TALK to your team.

Does this feel like babysitting? Maybe. But when you deliver your project on time you'll have the luxury to sit back and debate that point.

When the Train is Delayed

2009-10-07

Every time I go to the zoo with my kids, we have a different experience.

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.

Get a Professional Email Address

2009-09-30

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.

Image credit: Leo Reynolds

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!

Why Your Estimates are Optimistic

2009-09-23

I had an "Ah-hah!" moment at the recent Agile Edmonton meeting. I don't get a lot of those so I wanted to write about it.

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

Fix Your Mistakes

2009-09-21

Joe certainly seemed like the right fit. His resume looked fantastic - lots of software development experience with big companies, all the right keywords, enough years to have gained good experience. His interview was pretty good - he stumbled through some of the questions but a case of the nerves could have easily explained that.

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:

work with him for six months in hope of training him to the level that I expected him to already be, or
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.

Been doing some Wordpress work

2009-09-21

I've been playing a lot with Wordpress recently. I touched up the Arthemia theme on the Agile Edmonton site, moved my site from the Copyblogger theme to the Vigilance theme, customized the Vigilance theme a bit and then wrote up a couple of widget plugins for my sidebar.

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.

Is Your Architect a Bully?

2009-09-15

There's nothing worse than working with an architect who is more concerned with developers following his plan than he is with allowing his plan to evolve. On the flip side, there's nothing much better than working with an architect that is actively engaged with the team and helping to determine the solution.

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.

How to Cope with Interview Fatigue

2009-09-15

Let's start with a definition. I've decided to build on an existing definition of mental fatigue.

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.

Attitude Beats Talent

2009-09-12

As a software development manager, I've hired dozens of developers over the past decade. For each one of those hires, I've interviewed somewhere between ten and twenty candidates before finding the right one. If that sounds like a lot of work, it is - interview fatigue has caused me to make the occasional bad choice.

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.

Embracing uncertainty is hard

2009-07-31

From Mike Cottmeyer's Leading Agile:

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.

Find Happiness by Lowering the Bar

2009-07-29

Maybe this aligns more with the way I'm thinking these days or maybe it's just a byproduct of our current economic times, but there seem to be more people talking about lowering the bar on expectations as a means of increasing happiness.

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?

What do you get for $24 billion?

2009-07-09

From the UK Guardian:

IT is a very immature industry. With a small project, with good people, you can get a good solution. If it's big, people typically lose control.

An interesting article on the world's biggest IT project which is currently 5 years behind schedule and budgeted to £12.7 billion ($23.8 billion CAD). It makes a project that's $998 million over budget look like a drop in the bucket!

Managed IT environments don't allow for innovation

2009-07-06

Steve Boese on the standardized environments that IT groups create:

It is pretty easy for the IT folks to calculate how PC support costs are kept 'in-line' by enforcing a strict set of standards. It is also fairly simple to determine the costs to the company if a malicious computer virus infected the network and rendered all the computers inoperable for a period of time.

Since these costs are so easy to calculate and the benefits of a more open environment are subjective and difficult to quantify, it's rare to find an IT department that is open to new innovations. If you don't believe me, just try asking for an iPhone in your corporation. Unless you're in a (very) small company or a start-up, I'll wager that Blackberry is the standard and your request will be laughed at.

Boese continues:

In today's downsized, pressure-packed, do more with less world, we are asking our employees to be more productive and innovative, but in many cases not equipping them with the freedom to use all the tools in the workbench. Rolling out 'company-issue' PC after PC and clamping down on worker's online resources might have made sense 10 years ago, but that time is long gone.

IT's role (and compensation) needs to be considered more holistically so that it can actually enable innovation. Unfortunately, it's too often viewed as a cost center, a necessary evil that exists to prevent viruses and provide five 9's of server uptime.

Change

2009-06-29

I don't know if it's my age showing, but I find myself searching more and more for meaning in my career. I'm not interested in working meaningless jobs on large projects that aren't going anywhere. I'm tired of playing politics and dealing with bureaucratic systems that throw up artificial obstacles in the name of "due diligence". And I'm definitely finished with trying to build a team in a corporate culture that doesn't support it.

All of these are things that I've done. To some extent, you may have also done them (or more) at some point. But what I find peculiar is that I use to get a buzz from them. I used to get excited about going into a company and changing it, even if that change had to come in spite of the company itself. And, to a certain extent, I was successful in this endeavor. However, success is fleeting and all of these cultures eventually crashed to the ground like the blocks in a game of Jenga.

And so, like somebody that's frustrated at Jenga, I've decided to take a break.

I've been on this break for two weeks now and I plan to continue it until the end of the summer. I've taken a couple of interviews here and there but my current plan is to take some time to really think about what I want to do.

Actually, that's not quite right - I do know what I want to do: I want to work with software development teams to create kick-ass web applications for external customers.

That is:

I want to coach these teams to help them understand how to grow and adapt new processes pragmatically
I want to lead these teams around obstacles and teach them how to lead themselves
I want to manage these teams by working one-on-one with each of the team members to gain trust and inspire confidence
I want to manage projects to deliver working software within constraints while focussing on the highest priority features
I want to work with customers who expect delivery and are willing to tell the team what the product looks like

In short, I want to make a difference.

I've spent too much time in the last ten years trying to minimize risk. If I wasn't interested in working for a company anymore, I bided my time until the next opportunity came along, even if it wasn't quite right. By taking a bigger risk and completely breaking the continuity of my employment chain, I'm hoping that I'll be able to make a better choice and find that spot where I can make a difference.

Change is a good thing. That's really easy to say but not necessarily easy for most people to do. I'll be posting throughout the summer on my journey so I hope you'll stick around to read along.

Image credit: william.n

Away

2009-05-04

For the past month, I've been pretty well out of touch when it comes to my blog, Twitter, Facebook or any other kind of online social network. While the true cause of this is probably just laziness, I'm putting it down to a perfect storm of conditions.

I've been on a contract with Finning and just haven't had much time or opportunity to get online,
The weather is finally getting nicer so I've been spending more and more time outside and away from my computer,
The hockey playoffs are on!

Soon enough, the playoffs will be done and I'll have burned myself out with landscaping. That should free up some time at home where I can keep the blog updated and post the occasional Twitter comment.

Until then, I'll be enjoying the weather and the playoffs as much as I can!

This just in - TDD works!

2009-03-20

By comparing 4 similar projects at IBM and Microsoft, a paper has published what they say is empirical evidence that TDD works.

That is, the investment in writing unit tests before code ends up being repaid by spending less time fixing defects. According to the study, the teams reported a 15-35% increase in initial development time using TDD. However, the teams experienced a 40-90% reduction in defects per thousand lines of code. All teams agreed that the time saved in fixing defects offset the initial time investment.

Starting a podcast

2009-03-13

Photo by M. Keefe

I'll be starting a new podcast soon, interviewing (mostly) local folks that are using Agile methods to deliver software. The interviews will mainly focus on what type of software the company produces or works with, how Agile has helped the company, and what lessons they've learned that could benefit anybody going through an Agile adoption. This theme of promoting education and awareness is a natural extension from the work that I've been doing with Agile Edmonton and the new consulting work that I'll be doing with Quercus Solutions. The podcast will be called "Solid Solutions" and will be hosted on the Quercus Solutions website. I've already had a chance to interview Mack Male from Questionmark and Jim Whitelaw from BioWare. Mack's podcast is currently finished and simply awaiting the last steps of iTunes registration. After that, I'll be getting Jim's podcast into editing.

Sound editing is something that I totally suck at. I've chosen to use GarageBand on my Mac just because I already had it and it seems to have some great support for podcasting. GarageBand actually makes the process pretty easy but it still takes a lot of time to go through and clean up any of the sound files. I'm slowly getting better at it so I hope that's reflected in the quality of the podcasts.

If you're interested in being interviewed as part of this podcast series, let me know.

DemoCamp 6

2009-03-11

I'll be checking out DemoCamp 6 tonight at the University. Hope to see you there.

Easily secure website access with Hashwords

2009-02-16

Photo by Mirko Macari

I love web apps. Really...I love them. While the idea of computing in the cloud scares some people, it fits my needs perfectly. I'll sign up for a web app on the off chance that it might suit my needs. While it's easy for me to walk away from these apps if I find something better, there's one thing that I can't walk away from - the password that I used as part of the signup process.

Bad passwords are common

It's no secret that lots of people choose bad passwords. I usually shake my head at those folks and pat myself on the back for using a moderately strong password. Although my password doesn't use mixed case letters or special characters, it does contain both letters and numbers and has 8 characters. While it's not unhackable, it's stronger than most passwords being used out there. However, it suffers from a severely fatal flaw - it's the only password that I use.

Of course, I'm not alone - most computer users repeat passwords. It's just too much of a pain to remember hundreds of passwords and I'm not interested in writing them down. Software solutions that store my passwords don't really work either because I can only use them on my home machine.

So that got me thinking - if I have a decent password but my problem is that I repeat it, how can I be more secure? That led me to create Hashwords.

What is Hashwords?

Hashwords is a simple website that will take a master password, a website URL and create a strong password that is unique to you and the website. You don't even have to remember the password because you can regenerate it at any time.

Here's how it works. Visit hashwords.sideline.ca. Choose a password that you're going to use as your master password and type it in. Then, type in the domain of the site you need a password for. Keep the domain information simple here - type in google.com instead of http://www.google.com/accounts. As you type in the URL, you'll see your password being generated. When you're finished entering your master password and the URL of the site you're visiting, simply copy your new Hashword to be used. That's it.

The power of a Bookmarklet

It can be a bit clunky to open a new browser window or tab just to create a Hashword. The Hashword bookmarklet makes this process much easier.

Go to hashwords.sideline.ca, click on the Bookmarklet tab and follow the directions to drag the bookmarklet into your browser. Now you can access Hashwords from any site you want by clicking on the bookmarklet that you created. To make it even easier, the bookmarklet will automatically fill in the URL for the website that you're currently viewing. Visit the bookmarklets page on Wikipedia for more information on how to use bookmarklets.

How does it work?

Warning - if your eyes start to roll into the back of your head when people speak geek around you, just skip to the next section.

Hashwords takes your master password and the URL that you've supplied and combines them. It thens run one of three encryption algorithms (SHA1, MD5 or MD4) on this combined text to create an encrypted piece of text. This encrypted text is usually represented as hexadecimal. That means that it is made up of the letters A-F and the number 0-9. Since strong passwords usually consist of both uppercase and lowercase letters along with special characters, a further encryption is done on the text using Base64. Base64 is typically an insecure way to encrypt text but in this case it is simply being used to convert the encrypted text into a format that is even more secure. Finally, the encrypted text is chopped to a user-defined length of either 8, 12 or 16 characters.

Seems simple enough, eh? The beauty of this approach is that it is recreatable and virtually uncrackable.

But the security doesn't end there. Hashwords is implemented completely in Javascript using the JQuery framework. That means that there is no data sent back to a server so there is no way that your passwords can be compromised. Furthermore, these passwords aren't stored anywhere (because you can regenerate them whenever you need to) so there is no central list of passwords that can be hacked.

How do I try Hashwords?

Go to the Hashwords website and drag the bookmarklet into your browser. Then simply go to a website where you need a password. When you're on the login page of the website, just click on the Hash It! bookmarklet to launch Hashwords. Type in your master password and get your new Hashword. If you want to change the default settings, click on the Settings tab to choose the encryption algorithm, the length of your password and the characters to use in generating your Hashword.

After using Hashwords for a few months, I found some pain points in the workflow. Changing my settings from the defaults every time I generated a Hashword was annoying. Even worse was having to type in my master password every single time. To solve these issues, I turned to browser cookies. All of the settings are stored in a cookie in your browser for 7 days. Your master password is stored in a cookie in your browser until you close your browser. That means that you can use Hashwords conveniently on a public computer without any security concerns as long as you close your browser when you're done.

Final words

Let me know how you like Hashwords. It's a pretty simple little application but has made my online browsing much more secure without having to be tied to a single application that I install on my home computer. I love it and I hope you do too!

Agile Edmonton's First Social Night

2009-02-12

Photo by AGoK

Agile Edmonton meetings can be quick affairs. Folks show up at noon for a one hour presentation and then rush back to work at 1:00. While these lunchtime meetings have allowed us to have some great crowds (55 people for Janet Gregory's presentation), it doesn't allow for much networking.

One of my goals for Agile Edmonton is to create an Agile community here in Edmonton. So how can we create a community if we don't have any time for networking? Simple - we add beer. :) Every quarter, Agile Edmonton will be hosting a Social Night. I started calling it a beer night (or a booze schmooze), but Social Night is a much better name. Our first Social Night will be in just a few days - Tuesday, February 17th at 5:30. Come down to Hudson's Taphouse at 11248 104th Avenue. TekSystems is sponsoring the event and will be providing beer and food.

Hope to see you there!

googleMap name="Hudson's Taphouse" width="500" height="350" 11248 104 Ave NW, Edmonton, AB

Original post at Agile Edmonton Social Night

It's all about principles!

2009-02-05

I've been listening to the 4-Hour Workweek audiobook lately and absolutely loved this quote:

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble. — Ralph Waldo Emerson

I was recently chatting with someone about Agile and how it really only consists of principles so it can't really fail. What fails are the methods that people use to implement the principles.

If you don't actually take the time to grasp the principles then you're really just cargo-culting.

Habits you should cultivate

2008-12-29

Do you like to go for long coffees? Do you have fun at work? Do you feel that reading coding blogs at work is a complete defendable practice? Do you often ignore email and low priority requests? If so, you're not a slacker - you're just ahead of the curve when it comes to habits that keep you productive and motivated. At least that's what CNN says.

I've used all of these habits at one point or another. I've probably used some too much (I have no issue with ignoring voice mail, email and low priority requests) and some too little (I have a very difficult time lowering my standards and often use it as a way to procrastinate). However, I'm a strong believer in all of the habits that are discussed in the article.

In fact, I've found that encouraging these habits with my dev teams has ended up creating better, happier and more productive teams. These teams take more ownership, deliver better product in shorter timelines and create great incubators for training junior devs. It's true that these environments are ripe for abuse but I've only seen that in a few isolated situations. In fact, in the few instances where an individual abused this type of environment, it was the team that brought it to my attention.

What I've found more common than developers abusing this environment is that upper management will only tolerate these practices as long as things are going well. When things start to get a bit more difficult (timelines slip, budgets are too tight, et cetera), these teams of hard-working but fun-loving devs (along with me) are branded as slackers and held up as the reason that things aren't going well.

If you can find a company or a manager that can practice these habits in good times as well as bad then you've found a great place to work that truly values people.