Over the years I’ve been in very tight situations where things could have either failed miserably or succeeded. In each all of those situations I’ve seen two types of attitudes with the members on the team: negative and positive.

The negative people focus on all the reasons why things don’t work, state what “should have happened 5 years ago”, etc. (you get the picture). Though it’s good to have critical thinkers on the team, negative minded people can make it much more difficult for a project to succeed. This is especially true when you’re faced with an unexpected crisis.

Positive people tend to focus on two things:

• What has happened (i.e. get an understanding of what they have to work with)
• What needs to happen in order to be successful

When you have people that focus on those points they can resolve just about any issue and help the business succeed. They may not always produce the best (i.e. gold plated) results but they make things work while others may still be complaining about things.

A great example of this is when I lead a project to design the security layer for a new reporting application a few years ago. When I presented the solution to the entire development team not one person had a positive thing to say about it. Most of them had a negative attitude towards the project rather than providing constructive criticism and focusing one how it would help the business.

So the next time you encounter a problem or start on a new project ask yourself “What attitude am I going to take?”. You’ll be surprised with what happens when you focus on the positive.

For those of you wondering what happened with the security project, it was successfully implemented and, from what I hear, is still being used.

- Martin Giffy D'Souza

This is your new blog post. Click here and start typing, or drag in elements from the top bar.

Every so often I like to look back upon the past and think about the things I’ve learned and how I’ve grown. This past year has been an interesting one, and as I stop and reflect, here are the things that stick out in my mind.

Cooler Heads Prevail

There are many, many different kinds of personalities and temperaments in this world. In all cases that I observed, those individuals who had the patience to allow others to talk (or rant), remained calm, and provided an opinion uninfluenced by emotion were able to not only communicate more effectively but also came out ahead in the debates. Running into a “hot head” is inevitable, and being Mr. Calm will help your ideas be received and accepted.

Reduce Meetings
Meetings, meetings, meetings! You’re apt to find yourself invited to and participating in a lot of meetings at some point in your career. At times, there can be so many meetings that meeting organizers are forced to ignore the calendar conflicts of the invitees and “just book it”. There is nothing wrong with politely declining a meeting, or suggesting a shorter meeting with less people to help minimize the cost. A quick chat over coffee can often accomplish what the meeting was set out to do in the first place.

Play the Game
Politics. You can’t avoid it. As much as you might hate it, you’ll have to learn to deal with it in some capacity. If you don’t, you could see those that are adept at playing the game skipping over you as they sell themselves to upper management. Your work can be great, and it will earn you notice, but it will mean all that much more if you can sell it to someone that matters. Don’t be afraid to be proud of what you do. You’re making a difference and your work is making people’s lives easier and better!

What’s My Title?
At some point, you’ll probably find yourself in a role that you did not expect or ask for. I chose to grow into the role and accept that it was not what I signed up for, and I don’t regret that choice at all. It was a great learning experience and I developed some new and valuable skills. With the right perspective, these challenges can be transformed into opportunities.

Smart People Are Everywhere
There are a lot of smart people out there. If you keep an open mind you can learn boat loads from just about everyone you meet. As usual, I am taking away more knowledge from the past year than I could ever have hoped to impart. I am far richer for the experience and ever thankful for it.

- Chris Hritzuk 

Before having kids my sister was a very successful Financial Business Analyst at a major telecommunications company in Australia. She is now a stay at home mom with three beautiful and healthy trouble makers ... I mean kids.

After a few years staying at home she became a bit antsy and decided that she needed to do something to keep up her business skills, so she started her own company which sells face painting products online (www.serendipi.com.au). It’s now been over a year since inception and the company is doing extremely well and keeping her very busy.

I recently spoke to her on the phone and she made a very shocking statement to me. She said: “... When I first started this company I was a bit embarrassed. I went from a very challenging job and nice steady salary to a house wife who sells face paints online ...” I was really taken aback when she said that. I’ve been very proud of her for starting her company since day one.

So why was she not proud of her company when it first started? Well she was doing something that wasn’t “very glamorous” and was completely different from anything she had ever studied. In today’s society some people look down upon people that don’t have fancy job titles such as a doctor or a lawyer.

You should always be proud of what you do regardless of what others think. It’s that pride in what you do and strong determination that will help you succeed no matter what obstacles you may face.

Going back to my sister, now that her business has taken off she’s really proud of her company and you can see it each time you talk to her about Serendipi. I’m sure it will thrive even more now that she has a different attitude towards her business.

- Martin Giffy D'Souza

I've been involved in my fair share of data migration projects over the years, and I'd like to take this opportunity to share what I think are some of the crucial aspects of a successful migration that are often overlooked at the outset.  Far too often the drive is to move data as soon as possible to "prove" that we can do it, without consideration for what it really means to prove that we've done what we set out to do within the given time constraints.

Have You Considered NOT Using an ETL Tool?
I was once told that ETL (Extract, Transform, Load) tools were "The Great Equalizer" that allowed individuals who did not have experience with databases to still complete a migration.  I've never really understood this way of thinking.  I'd much rather pay to have my team trained in the database architecture(s) that the migration is going to feed.  I've spent my entire career working with and developing software using Oracle, and I believe that a solid understanding of your database and the features it ships with will allow you to move data faster and more accurately than any ETL tool. This is especially true today as Oracle allows you to connect seamlessly to other database technologies using Oracle Gateway and heterogeneous services. Databases are born to manage data.  Why not harness that power?

Defining Business Entity Ownership
Every business, no matter the size, is divided into departments.  In smaller shops, a single person could be the entire accounting department, payroll department, HR department, etc.  Defining which department owns which business entities (for example, the "Customer" business entity), and therefore the elements of data for that entity, accomplishes two very important things

1. Getting business sponsors.
2. Provides developers with access to people who use the data every day and understand it in the context of operations.

You will not regret the up-front effort this requires.

Working With Erroneous (Bad) Data 
Every migration project that I've worked on was the result of a move from a legacy software system to a new and improved one.  What you can expect from a legacy system is some very questionable data.  You must define a sound strategy for

• Capturing bad data
• Excluding bad data
• Transforming bad data
• Reporting on all of the above

Reconciliation
The prior paragraph segues nicely into this one. This is where we talk about proving that you've successfully migrated the data.  The business is going to expect all manner of checks and balances before it gives you the rubber stamp of approval.  You will be expected to provide basic counts for what you started with, what you left behind, what you changed, and what you ended up with.  There will also be a more complex Relational Reconciliation effort: "Every customer must have a mailing address."  Documenting your reconciliation is crucial for getting business signoff.

In a future post I hope to talk about a framework that has worked well for Oracle to Oracle migrations (that may be a bit misleading, because I've turned many Non-Oracle to Oracle migrations into Oracle to Oracle migrations!).  The framework makes it very simple for developers to deal with bad data, create a simple reconciliation, and report on it all; which many times has been enough to get business sign-off.

Standardizing the Approach
I cannot stress this one enough.  Getting everyone on the same page from an approach perspective will save you countless hours of headaches and rework in the future.  Obviously this is true of any development effort, and I believe it is more important for migration projects.  Why?  Because data migration is all about doing the same thing over and over again, just with different data sources and targets each time.  Your development team will be unified and the work will be streamlined.  It will make your reconciliation effort a breeze (as much as it can be a breeze).  This also means standardizing on coding practises.  I used to think that coding standards were nothing but fluff and that if you became adept at reading code, standards would be unnecessary. Oh how I have seen the light!  And you have to be strong about enforcing the standards.  If you need to get heavy-handed, do it.  Once you decide on standards, stick to them! (Unless there is a very good reason to modify them).  I am reminded of The Goose Story.  Let's help each other achieve our common goal.

That's it...for now.  I hope reading this post has proven both insightful and helpful.  Happy Migrating!

- Chris Hritzuk 

One of my biggest pet peeves when attending a presentation is that the presenter spends most of the time looking back at the screen and talking to it instead of the audience. The second they do that the entire presentation has lost its focus and the audience has lost interest.

We’ve all been through these types of presentations before so I won’t discuss why you shouldn’t do it. Instead I’ll focus on why it happens and how to get around each issue.

Too Much Content
When you have a lot of text on a slide the natural tendency is to turn and read the slides. Everyone else in the room is doing that so it’s only natural that you, as a presenter, do the same.

If you’ve read any book, blog, tweet, etc on using slides in presentations they’ll all say to reduce the number of words on your slide (or even better don’t use slides). The easiest way to do this is create 2 slide decks. The first will be for handing out (with all your notes). The second should use “visual aids” to help emphasize your current talking point.

You’ll notice immediate impacts by doing this. Instead of everyone focused on reading the slide they’ll be looking at you. As a result you’ll naturally look back at the audience rather than turning around and staring at the screen.

Complex Data
I once had a manager who gave weekly meetings about how we were allocating our time. Some of the charts that were on his slides had so much content that I could barely read it a few meters away. Of course he had to spend the entire time looking at the screen to decipher everything rather than facing the group.

When you put up charts and graphs that are complex the same thing happens as when you put too much content. You’re pulled into facing the screen to decipher what is going on.

To get around it either don’t put up the chart/graph or put up a very simple chart and highlight the key areas. You can easily do this by greying out everything except for the one key element that you’re talking about. Using this simple technique you won’t feel the need to turn around and decipher what is going on in the chart/graph.

Not Enough Preparation
I’ve met some people that are proud when they say “I whipped that presentation up in 30 mins”. I groan when I hear this since I already know how the talk is going to go. These presentations tend to have slides with (you guessed it) too much content and complex data. They use their slides as a guide for them rather then something to help you, the audience.

If you’re going to present to other people the least you can do is practice. By practicing you’ll find that you don’t need to litter your slides with reminders for yourself. If you do need some reminders then use some sticky notes with key words. 

Don’t be fooled into thinking that clear and concise presentations are quick and easy to create. They’re the ones that take the longest to create since the presenter has given a lot of thought into the flow and structure of the talk.

How much time should you practice and prepare for? Well, it depends. For internal meetings estimate the total man hours your presentation will cost the company. For example if your talk is 1 hour long and 10 people are going to attend, spend 10 hours on it. Some managers will gawk at that amount since it seems like a lot. The total time spent will be 10 hours (your prep) + 1 hour x 10 audience + 1 hour x 1 presenter = 21 hours. Seems like a lot but look at the results. That’s 21 hours and the result is that 10 people know a lot more about the topic you just discussed. The alternative is that you spend 2 hours (prep) + 1 hour x 10 audience + 1 hour x 1 presenter = 13 hours total. For 13 hours no one gets anything out of it, people get bored, and the company just wasted time and money.

Public talks (conferences, webinars, etc) are slightly different. I tend to spend anywhere between 40 to 60 hours (sometimes even 80 hours) preparing when I give public talks. It may seem like a lot but it really isn’t. If there are over 100 people in the audience then they expect a good, entertaining, and educational talk.

Conclusion
Please remember, talk to me … and not to the screen  

- Martin Giffy D'Souza

Ok, I may have over exaggerated with the title but I do have an interesting story behind it. Before continuing I think it’s important to quickly cover what code reviews are.

Code reviews are when a developer reviews another developers work. They look for bugs, ensure standards are met, efficiencies, etc. This is common practice in some work place environments but not all of them. As you can imagine not all developers enjoy having their code reviewed so they tend to dismiss all the benefits about code reviews.

Now back to the story behind the title. A friend of mine works at an international oil and gas company in Calgary. He recently had to drive to Edmonton (three hour drive) for work. I was shocked when he told me some of the organization’s procedures when traveling for work:

- They must inform a supervisor before they leave and when they arrive.

- Any planned breaks must be submitted and scheduled ahead of time

- They must not exceed the speed limit while driving (the company cars have GPS trackers that log speed)

If they break any, yes ANY, of these rules they will be fired immediately! That’s right, if they drive a bit over the speed limit while on the job they’ll get canned.

At first I thought this was a bit excessive until he started to explain the logic behind these rules. Each year the company sustains work place injuries ranging from minor injuries all the way up to death. Most of the serious and fatal injuries occurred because of a series of several small mistakes that lead to an unfortunate situation. The company has spent a lot of time and effort to reduce the small mistakes which in turn has helped then reduce the number of injuries, and deaths, in their organization.

What the company found is that if you reduce the number of small injuries, which are caused by small mistakes, there’s a direct correlation to a reduction in the number of deaths. Another way to think about this is to compare it to a triangle. The base represents minor injures and the top represents death. If you trim the bottom down the triangle becomes smaller and this the number of deaths are reduced.

How does this relate to code reviews? Most major software bugs that I’ve encountered are usually triggered by a very small mistake or a set of small mistakes. If you can reduce the number of small mistakes ahead of time you can reduce the number of bugs, both minor and severe, in your final product. Code reviews can help catch these mistakes before they get to a test environment. The bonus is that two developers can learn from the mistake: the developer and the reviewer.

-Martin Giffy D'Souza