Craig Pardey

1. Automation is good.
2. People make or break a project. Thanks Joel.
3. Coding the right tests is hard, but infinitely valuable.
4. “Cutting edge development” describes the processes and principles, not the technologies.
5. Software must be tested in a representative environment.
6. Knowing the gaps between marketing and reality in your vendor’s software is valuable.
7. The timing of a discussion directly influences its outcome.
8. Metrics are useful but can be gamed.

Deploying a sufficiently complicated application into a corporate environment involves navigating a sea of paperwork, getting all the appropriate “approvals” in place, co-ordinating with department managers to get time slots from their staff, and so on.

Knowledge silos

On Release Day all the right people from the various departments - DBAs, application server administrators, server administrators (both Windows and Unix), desktop support, storage experts - are all sitting in their cubicles at the allotted time waiting to check their checkbox, waiting to mark their task as Done, so they can catch the 5:31pm train home.

I read a great quote in I’m feeling lucky. It described a note sent from one Google employee to another as he handed over a piece of software.

• Here’s what I’ve done.
• Here’s how it’s running.
• Here are some things to look at.
• Here’s what’s going to go wrong if it goes wrong.
• Here are the steps to turn it off.

These five points would be invaluable documentation to any new code or functionality. Imagine how much time could be saved if you had this information before embarking upon a code change.

Automation isn’t about quality, it’s about scale.  Manual processes don’t scale.

Each part of your process that you automate gets you one step closer to continuous deployment. For many teams, automation is a Quadrant 4 activity - not urgent, not important - but on my teams it is a Quadrant 2 activity - important but not urgent. We allocate time each iteration to improve our automation because it frees up more time for development.

Please use affirmative phrases when naming your boolean variables and flags - I find that it makes code much more readable.  This is particularly true when naming the configuration settings used to turn features on or off.  If the setting is named in the negative then I have to use a double negative to enable it, and everyone learnt in high school that double negatives are a Bad Thing.

For example, if I have a feature that sends emails and I want to make this behaviour conditional then an appropriate variable name would be “boolean sendEmail = true”.  It’s easily comprehended.  Contrast that with the same feature phrased negatively: “boolean disableEmail = false”.

When changing your password, please remember that it must be between 5 and 8 characters in length and should contain both letters and numbers. Special characters (e.g. #, &, @) must not be used as they will not be accepted by the system. Passwords consisting of all letters or all numbers are not recommended. Although TD Canada Trust does not require you to change your password, we recommend that for security purposes you change your password every 90 days.

[Read More]

Many large companies have explicit policies around which development tools to use. For example, “Here at Really Big Corporation we use CVS, Ant and Eclipse”. I understand that companies need to limit the proliferation of tools to ensure familiarity and supportability, but sometimes a little flexibility would be nice.

When I hire a tradesman to do work on my house I don’t tell him that we use handsaws here, not tablesaws. I trust him to use the tools that make him the most productive.

There are many things to consider before switching to VOIP.  My wife and I switched to VOIP in March out of frustration with our phone provider, Bell.

After two months of VOIP phone service we’ve decided to go back to a standard phone line. There are many reasons that factored into our decision:

• It was very unreliable
• It cost more than a standard phone line
• It didn’t work with our security system

I’ll expand on each of these in detail.

Recruiting is difficult. Most of the top talent already have jobs and are rarely in the job market. As a recruiter (or a headhunter, or a talent scout) these are precisely the people that you should be trying to attract.

There are a few simple guidelines that might help you generate genuine interest in the role you’re trying to fill.

1. Try to build relationships with candidates, not just a contact database. I need to know that you are someone I can work with and can be trusted to be discrete. Let’s have lunch together.
2. Proof-read your email.
3. Give me a detailed description of the role including the actual company name and location. Leave out the technology buzzwords - truly great developers can operate effectively in any landscape
4. Do not ask me to send you “an updated copy of your resume in MS Word format”. I don’t know who you are or what you’re going to do with it; what happens if you unknowingly send my resume to my current employer?
5. Be discrete. Don’t call me on my work phone. When you call my cell phone always ask first if it is OK to talk and listen to my answer. If I say no then just say, “OK, let’s talk later” and hang up.

Following these simple rules will dramatically increase the quality of your candidates and get a higher response rate to your communications. Who knows, you might even make more money because you’ll be able to consistently deliver the candidates that nobody else can find.

After a decade of abuse I’ve decided to ditch my Bell landline in favour of VOIP.

My last Bell bill was $60.26 for a basic phone with 2 features.

I did a lot of research into the various providers in Canada. My short list of potentials was

• Vonage - the biggest player
• voip.ms - the cheapest player
• AcroVoice
• Cogeco

In the end I went for AcroVoice because they seem to have the best mix of service, simplicity and professionalism. Their basic service is only $10.95/month and they provide pre-configured hardware at a reasonable cost.