Relocation

I wanted to go over the reasons why I moved from California to Indiana back in 2005.  My wife and I were recently engaged and wanted a family.  I owned a 418 sq. ft studio condo and just to move to rent a one bedroom would have been about $500 more per month.  It was an agonizing decision.  Where do we move to? We looked at websites, almanacs, talked to people, etc.  But what it really boiled down to was:  we wanted to be near someone we knew.  At the time, we had friends in Seattle, and family in Dayton, OH, near St. Louis, and Houston.  We thought that Seattle was not as affordable as the Midwest, and Houston was a little too hot for us.  So we decided to look at Dayton & St. Louis and surrounding areas.  Since we were from California, we didn't want weather that was too extreme, so we ruled out metro areas that were close to the Great Lakes (Chicago, Detroit... lake effect snow).  We wanted a metro area that was fairly large, say 1 million + (bye bye Dayton), but not too big that we would have to live far from downtown to be in a good neighborhood (bye bye St. Louis).  So we ended up narrowing it to:  Cincinnati, Columbus and Indianapolis.  So, we planned a trip.  We thought that Columbus was too expense, and Cincinnati recently had race riots.  But there was something about Indianapolis that we liked, so we decided to move.  Jen and I quit our jobs, sold the condo, got rid of everything that wasn't necessary, packed up our bags and moved.

Advice:

-Family/friends - Most of our friends and family are in California.  It has been hard.  We try to fly out at least once a year, but sometimes it's not enough.  Facebook helps.
-Amenities - If you move to a smaller metro area, think about the amenities that you won't have.  Indianapolis doesn't have a professional hockey or baseball team, and it doesn't have any amusement parks.  It has a lot of other things, including (surprisingly) really good restaurants.
-Weather - If you move, don't underestimate the weather... but don't focus too much on it.  The first time I drove in the snow was terrifying.  After that I got the hang of it and it's not that big of a deal.  Around February, we get sick of the cold and want to go back to California, but it soon warms up.
-Not knowing anyone - Jen and I aren't very social people, but if you are, you might want to try and make friends before you move through social networking websites, clubs, churches, etc.
-Job - We were fortunate enough to be able to afford the absence of a paycheck when we moved, but now we can't.  We wouldn't be able to make this move again without having a job first.

Software Quality Assurance

I wanted to give my thoughts about SQA.  My experience has been with web forms and web sites.  I also did help desk support where I had to find bugs and tell IT.  You have to recreate the bug, which is the hardest part.  But I wanted to focus more on my process for testing a web site before it moves to production.

• If there is a submit button anywhere, I like to click that first without entering any data to see if there is any validation on the text boxes.  
• I also like to know what the business rules are with the text boxes and go outside of that to try to break the code (e.g. I will try and type letters in a phone number field).
• Of course, you have to look at the overall look & feel.  Make sure that the labels are lined up with the text boxes (A lot of times this will be browser specific, so try a couple different browsers).
• Go to a different web page, then click on the browser's back button to make sure that it still looks the same.    
• Make sure dates have date pickers in them, if that is required.  

Business Analysis

I wanted to share my thoughts on Business Analysis based on my experience. My experience has been with companies who have slow, legacy systems and they want to upgrade. My process is as follows:

Sit with ALL the SME's as they do their job.

Deliverables: Process maps, screen prints, user instruction guides, new requirements, SME sign off,

Sit with management.

Deliverables: management override processes (watch SOX...) (try to incorporate all this in the new design.

After you have gathered/elicited everything you can from the SME's, design a new screen using a mock up. Make sure the SME's know it's not what the screen is going to look like, only a mock up. When you get sign off, deliver to technology.

Deliverables: mock up

Final Deliverable: Business Requirement Document (BRD)

Technology: Watch the team very carefully. The first issue is web form vs. windows form. Be careful about web forms and only use them when absolutely necessary because they can be slower (J-query has helped though...). Try to be involved as much as you can and understand what's going on from a design perspective. Don't be afraid to get management involved if it's not going the way you think it should... but give the IT team space as well.

Deliverable: Functional Document

Try to test once they have a screen, or if you're iterative, once something is working. Refer back to the BRD and make sure that all the requirements are being met and that if there is functionality being put in that wasn't required, push back on IT. If they're adamant about keeping it in, try to get sign off from the SME's as an IT initiated scope creep. Try to get the SME's to look at the screen's as soon as there is something to look at.