What Being Agile Means to Me

August 3, 2015
Agile-Scrum-Process - New Page

If your objective is to keep your customers happy and satisfied, the best way I have found to do that is through involving them with your development and releases from the outset.   When you show them that you value their opinion, take it to heart, and get their feedback from the beginning, not only will they be happier, but they will have the exact product they asked for.  If I created a mantra for my company it would be ‘Early and Often’,   builds, testing, integrations, collaboration, promotions should be done early and often.  The faster we turn around features to the end users, the faster we get feedback, and the faster they’re promoted to production.

From the developer, and release engineer perspective everything needs to be automated.   Nothing should be left to manual processes which can be time consuming and error prone.  The objective for releasing a software product should always be to strive for making a non event.   Everything needs to be repeatable, and automated, the only people that should worry about a release should be the marketing folks.    Integrations and testing them should be automated and done automatically on check-in of source code.

My Experience

I learned through trial and error, and experience what works for me and my organization.   When I started my career in IT I was hired as a junior Java Developer, from the outset my role included being the release specialist.   The first couple months on the job I implemented a linux based source repository called Aegis which forced clean builds and approvals prior to integration/check-in into the master branch.   So naturally I have always been interested in different Change Management and Project Methodologies.   The first three years into my professional career, the company I was working for was transitioning to CMM L3 which I was heavily involved in as I myself transitioned out of the developer role and became the Configuration Manager for the organization.    CMM essentially is a document and process standard which depending on the level supported forced repeatable standards and processes when it came to everything from sales, development, corporate training, and support.

A small part of this was the organized structure for project management and development, CMM itself didn’t necessary cared how you conducted development or managed projects, but it wanted to ensure you followed a standard / repeatable process and plan.   When I was in school, Agile wasn’t on the curriculum, we spent our Project Management classes only learning only the Waterfall model, both methodologies can fit into CMM.


CMM stands for Capability Maturity Model, and is a standard for policies/procedures that allow organizations to have repeatable and sustainable processes, it was primarily popular in government.  Generally speaking CMM was very popular 10+ years ago, and is slowly dieing to the Agile movement.   I spent a couple years assisting our organization in the transition to CMM L3, and preparing for an audit.  In doing so I learned a lot about what does, and doesn’t work, and just how much of a waste of time/money it is for an organization to follow such rigorous processes.

CMM has five tiers:

  • I: Initial (chaotic, or ad hoc);  generally everyone with an undocumented process
  • II: Repeatable; a  process which is repeatable, so a set outline of required documentation
  • III: Defined; a standard practice defined/confirmed to business processes
  • IV: Managed; quantitative measurements
  • V: Optimizing; process optimization/improvement, ever evolving.

Obviously given this, technically any project management methodology to some degree fits within CMM.   We built rigid guidelines on what documents were required for a project to be signed off at any stage, and our QA department performed regular audits to ensure the processes were being followed.   Eventually I built an automated way of sifting through our source repository (Perforce) for documents, and performed automated audits.  We had dozen’s of required documents from Sales to Go Live, some of which spanned 100’s of pages.   We would spend weeks/months on a Design document or Functional Specification only to have everything change by the end of the design phase, or worse yet, by the end of development.   It wasn’t uncommon for us to spend a month collaborating on a design document with a half dozen programmers & architects only to have everything turned up sign down when we tried to get sign-off by the customer/stake holders in order to move onto the next phase.

Repeatable and definable processes themselves were actually quite beneficial, my concern revolved around requiring sign-off with each document and each phase, many of the documentation were never read, and requiring sign off just delayed project start.  I would rather spend the lost time building prototypes or starting development, while collaborating with the customer throughout development.

So I saw from the outside looking in on all the projects what I felt worked, and what was deemed a waste of time.  On one particular project which was fixed bid, so we tried to manage risk/limit change as best as we could to prevent our profit from shrinking.  We spent nearly 3 months designing the system before we even touched a line of code, and that was after writing and getting sign off the following documentation (that I recall, I know there was others):

  1. Statement of Work
  2. High Level Estimate
  3. Project Charter
  4. Configuration Management Plan
  5. Detailed Estimates
  6. Project Management Plan
  7. Quality Assurance Plan
  8. Quality Control Plan
  9. Test Sweeps
  10. Functional Specification
  11. Detailed Design
  12. Release Plan
  13. Weekly Reports
  14. Gantt Charts
  15. Acceptance

As you can imagine, a great deal of time was wasted on documentation that someone read once, and generally was never looked at again or followed.  It was my job to take all the documentation and archive it in our corporate library, and audit each project to ensure they followed the appropriate policies and in the correct order.   Each step had to be completed before we could move on.

Waterfall Model

My first project team was isolated from the rest of the company, we predominately followed a hybrid Extreme Programming/Waterfall model, while the remaining project teams followed Waterfall.   As the months went by our product became vapour  ware, and the team dissolved, and we became solely a waterfall company.   I was a big proponent of Waterfall when I was a developer, but once I was on the outside looking in, and saw the amount of effort needed to keep track of every minute detail, and ensuring the gantt charts were accurate on a daily basis, I realized just how ineffective it was as a method of measuring progress.   At the end of the day, it allowed managers to see pretty graphs, and it made them feel better about the progress and that was really it.   It takes years of experience as a programmer on a project to learn how to build accurate estimates, and a gantt at the end of the day is only as good as the estimates.   Which are generally very poor.

Waterfall Model

Waterfall Model

Change Management was managed via meetings every two weeks with the customer, because we already had a defined schedule and the projects were usually fixed bid, it made it difficult to approve new changes.    The customer didn’t want to pay more, and we didn’t want to cram more work into a finite timeline.   Approved features were added to the gantt and each of the above documentation were updated to reflect changes and pricing updates.  More often then not, the customer didn’t want timelines to change so we worked increasingly insane hours to keep up.

I tend to be very analytical and structured by nature, I create daily todo lists for both work and personal, and follow them religiously.    But my aim has always been to do my best to complete them, and if I don’t they flow into the next day.   But even so I only believe in process and structure that allows my project to proceed effectively and efficiently, thus I feel it’s best to do little documentation, move into development as quickly as possible and follow up with the customer on a weekly basis to ensure your project is on the right track.   We manage change by advising them that changes will require work to be removed, or the timelines move out.

Agile Development

Being agile is essentially a grouping of development methods which promote collaboration, self-organizing, adaptability and cross functional teams.   It encourages early development, delivery, and continuous improvement.

Extreme Programming

When I transitioned to my current company three years into my career, I was hired as their first full-time programmer.   This allowed me to single handedly create the policies and procedures from the ground up.   These processes have changed drastically over the years as I feel process should always be evolving, which is the whole point of being Agile.  In the beginning we fully implemented Extreme Programming (XP), as this is what I had experience with.   I read and learned as much as I could as we only utilized the programming aspects of XP at my previous job.   We had two programmers in a shared room, so we glued cork to one wall, and used string to separate the stages of a story, queue cards were used to keep track of features and bugs.


Extreme Programming is essentially taking the traditional waterfall model, and repeating in cycles every two weeks.   This allowed us to define or refine, development, and have something close to releasable every two weeks, the constant collaboration with the customer or stakeholder of the project ensured the end result was always being refined, and final product was exactly what everyone wanted.   This also allowed us to continuously integrate, test, and release the build to QA every two weeks.   One of the first things I did was to install Subversion, and a continuous build environment called CruiseControl.    We used the cork board to track user stories and bugs, and it had three columns:  Backlog, In Progress, and Complete.   We successfully used the board for nearly a year, but I wanted more metrics, I wanted to know quickly what our velocity was, and how close our estimates were.   At this point we were transitioning to working from home part-time, and provided a good opportunity to try out a web application to manage our projects.

I installed XPlanner,  this allowed me to get the metrics I wanted.  We still used story points, but I preferred tracking hours as I wanted to know how accurate my estimates were.  To this day I still use both story points and hours to track my work.   We used junits to test our business logic, and manual testing for acceptance and regression testing.

As the years went on we refined our processes, and now we use something more similar to Scrum.


Around 2007 we implemented Selenium to automate much of our regression testing, we still use manual testing for boundary and capturing errors or missing regression tests however.   Automated regression testing combined with CruiseControl allowed us to build a continuous integration/testing environment and report back as soon as we check in source code if we broke our baseline.    It was our policy to build user stories and/or tasks that took no more then 1-2 days, so we had to check in our source code atleast every other day.   This allowed us to know quickly if everything is still compiling and passing our regression tests.   Once a new feature is developed we build in new automated regression/acceptance tests to validate the the feature.

I wasn’t entirely happy with XPlanner, I was on the look out of a replacement for years  until I found one I was finally happy with in Jira – Greenhopper around 2008, and   we’ve been using it ever since.   Internally we actually follow two different agile methodologies, Scrum and Kanban.   Generally internal non development projects follow Kanban, and the rest follow Scrum.   I’ll discuss our Kanban procedures more later.

We manage change management on an as needed basis, one of the aspects of software development that I have learned, and have never shied away from is scope creep.   If we don’t allow scope creep, at the end of the day our customers will never be satisfied with the end result, no matter how prepared you think you or they are.   There will always be changes after they have saw and played with the product.    In saying that, there’s always a fine balance of managing what can wait until a patch at a later date.    At the start of a project we define all the user stories for a release, lets say we have release 6.3 planned for a October 1st go live.   We get the team and stakeholders together, and select all the user stories with story points estimated, at this point we have an idea of what our average velocity is for a two week iteration based on previous projects.   So we know approximately how much work can be completed within the allotted time.   We always work on features from highest to lowest priority, and hardest to easiest.   This allows us early on to know if a release may need to be refined or shifted.

At the start of the release we choose which features will be chosen for the next Iteration (also sometimes called a Sprint), the features are chosen based on the priority and difficulty of the user story.   Once a story is added to a release, the programmers select which stories they want to work on and create sub tasks for the user story with hour based estimates for each task.   The iteration is started, and generally every day we try to meet internally to ensure everyone is on the same page, however we’re a small team, often times we don’t have a formal stand up meeting as we talk over IM for much of the day and any questions come up naturally.   At the end of each iteration we close off on the finished stories, and migrate any open stories back to the release backlog.   Naturally these stories move back to the top of the queue, and are most likely going to be selected for the next iteration.   The completed iteration is deployed to QA, and our customer/stakeholders are provided access to give us feedback.   This provides our customers ample time to provide feedback, often times a customer doesn’t necessarily know what they want until they see the end product, thus its important to refactor and refine your product to make changing it as painless as possible.   Any feedback is logged as user stories and assigned to a future iteration.    Even for internal product releases we always have at least one customer represent our entire customer base, its always someone from our User Group.   Near the end of a release cycle we provide a half dozen users access our QA site for acceptance testing and feedback.


Our second methodology we follow is Kanban, its essentially like Scrum but with less process, more similar to XP.  Thus we generally don’t follow it for development releases,  we use it internally for operations, marketing etc. One of the biggest differences you’ll see with Kanban from Scrum is the removal of Iterations.  The purpose of Kanban is to remove the time box, this is especially beneficial for those development teams who also do maintenance programming or are likely to be interrupted during an Iteration.  Kanban came from Toyota where they developed a card system that required a card to be presented to each assembly line to ensure they didn’t have excess materials being used then necessary.

The time box is instead moved to the workflow state.   Each workflow state such as TO DO, or In Development limits the amount of tasks which we call Waiting in Progress (WIP).  If we limit the TO DO workflow state to say 5 use cases, this forces the customer to remove a TO DO item back to the product backlog if they change their mind and want to add a new item.

The developer’s then pull this TO DO use case into the In Development or ongoing workflow state when they’re ready to do so.   The releases to testing are then event driven, so when the developers are ready to release the product to Testing they will do so.   This can be on a use case per use case basis or weekly, but generally won’t be any longer then every two weeks (if its a very big use case).    We almost never use Kanban for development unless we’re working on a release without a timeline and we’re expecting interruptions.

Release Management

At this point we begin planning our rollout, starting with our SaaS customers, and then coordinating potential upgrades for each of our self hosted customers.

We manage a release wiki on Confluence for tracking story questions, or providing release / iteration burndown graphs for progress reports.   Naturally a release plan is always very minimal, we list the stories for the release, a couple graphs showing progress, and any large user stories with rough mockups/questions.   As mentioned earlier, we try to do only as much documentation as needed to get started on coding, we allow the product itself to speak to the customer and refine from there.   I’d rather spend a half a day coding something for them to see and play with, then building a document, because they will have more questions/refinements after playing with it then after reading a document.

A typical release plan

A typical release plan

Even though we pride ourselves on being stable every two weeks, we support a half dozen browsers and various release environments.   So we still give ourselves one month after code complete to finish off any last minute testing before migrating to our SaaS or self hosted customers.   I have always been very paranoid about buggy releases, and would rather over prepare for a release, then release something completely buggy and deal with the aftermath.

Agile-Scrum-Process - New Page


We usually strive for one major, and one minor release a year.  Meeting atleast twice a year to go over and re prioritize our backlog of features, we build an annual roadmap which we strive to meet, however at times we take on “for pay” features, and this delays baseline features from our roadmap.


I believe being Agile falls under not only development, but all aspects of a business including operations.    While we prefer to keep development documentation to a minimum, I’m not anti documentation.   I believe in minimizing bus factor, so every repeatable task, policy and procedure must be documented in case a new employee needs to be quickly brought up to speed.   Our document archive contains hundred’s of documents ranging from how to install/deploy a development server, frequently asked questions for  salesman, to Success Profiles for Human Resources.


Part of being Agile is keeping everything as simple and automated as possible, this includes all of our user and server environments.   Years ago we moved all aspects of our business to the cloud including the following:

  • Email
  • Calendars
  • Meetings
  • Documentation
  • Source Repositories
  • Continuous Build servers
  • QA servers
  • Issue Tracker
  • Collaboration
  • Communication
  • Production servers

This allows us to work without worrying about backups or maintaining infrastructure and it allows us to focus on what were good at which is supporting and developing our product.   Ina addition, our development environments are setup as virtual machines to allow a new programmer to easily spin up a new build environment, and in my case I love to use them to run automated tests in my virtual machine while I continue to work on my main system.   Plus I run Ubuntu as my main development box, and use Windows based virtual machines for my local continuous build environment.

Where do we go from here

I feel like if your not always looking for ways to improve your processes then your likely delusional, and no one has everything running absolutely perfectly, there’s always room for improvement.   In my case, on my wish list is to further modularize our product to speed up build promotions and minimize risk of upgrades, as well as automate build promotions.   Right now to deploy a new build to production it requires a resource to be available at night, to upgrade the WAR, and reboot the instance which requires a 3-4 minute downtime of the server.




OffGrid, Technology

My Obsessions: Self Sufficiency

August 2, 2015

My obsessions almost all delve around self sufficiency, whether its cars, housing, agriculture, grey water treatment systems etc.

It started about 12-13 years ago when I first heard about Earthships,  I don’t recall where I first heard about them.   But I’ve loved them since day #1,  Desiree isn’t as keen on living with earth around 3 of 4 walls.   I suspect when the time comes we’ll build a traditional house with all the mechanisms in place that I cherish, such as the grey water system, giant indoor planters, off-grid, and tons of windows.


Earthships were created in the 70’s in New Mexico by Architect Michael Reynolds.    They’ve evolved in the last ten years, early on when I first started researching them much of the designs included circular or horse shoe shaped modules.   That design seems to of disappeared from their website over the couple years, I’m not sure if there were specific reasons for it or not but the modern design has only the exterior rear walls now with earth rammed tires.

Older "U Shaped" Earthship

Older “U Shaped” Earthship

"Modern" Earthship

“Modern” Earthship

An Earthship was designed to face South to maximize natural light and solar gain during the winter months.  The point of an Earthship is to use supplies which are most recycled to keep the costs down, and utilize systems which allow for self sufficient living through water reuse, foot production and energy storage.

images (1)The thick / dense rammed earth tire walls provide thermal mass that naturally regulates the interior temperatures no matter the temperature outside.  The tires are often put together by two individuals, one does the ramming, often with a sledge hammer pounding the earth into the cavern, while the other provides the soil dumping it into the hole with a shovel.   A single rammed tire can weigh up to 300 lbs, and often adobe or concrete is sprayed on to finish the wall.   Internal, non load bearing walls are often made of recycled pop cans combined with concrete, and plastered with adobe.   The techniques used in building an Earthship uses up to 80% less concrete.  The tops of the exterior/interior walls are topped with wooden trusses, and insulated to prevent heat loss.

Grey Water System



This aspect of the Earthship is what drew me to it in the first place, I love how you can reuse all the wasted non toilet water for reuse either in the toilet, or for feeding the planters.    All water use within the house is captured via cisterns attached to eaves on the roof., the cisterns are buried  to be protected from the sun.  The water from the cistern is gravity fed into the WOM(Water Organizing Module).   The water is now safe to use for drinking or use.    This water is stored, and treated for use throughout the house using a WOM  to treat the grey water inside the building, and sewage from the toilets separately.   All interior non toilet water (grey water) is reused for for both interior and exterior botantical cells.  As you can imagine, this uses far less water then a conventional house as nearly all water is used atleast twice before it  feeds the botantical cells.

In doing so we eliminate the need for both public sewage, and spectic systems.   The system can also be setup to flow entirely into a conventional septic field/tank.



Interior Grey Water Botantical Cell

Interior Grey Water Botantical Cell


An Earthship creates an environment which provides not only food, but cleanses the air, and recycles the water via indoor botantical cells.  I’ve even seen indoor ponds with fish, or fruit trees.













I have always wanted to be off the grid, but I feel like we’re close to a breakthrough in solar cells and battery storage.  I’d hate to throw down 20k only to miss out on the latest technology.    Being that we live in British Columbia we generally get very little sun for 4-5 months of the year, so I suspect we would need to supplement with wind turbines.    I think Tesla is close, they’re now selling home batteries with ample storage for a reasonable price.   I suspect within 2-3 years the price of batteries will halve.

The Earthship is built to regulate temperatures on it’s own as noted above, so electricity isn’t needed for heating or cooling which is one of the biggest expenses when it comes to electricity.

Modern Housing

Des isn’t as keen on living with earth around the house, so I think our plan will end up being a modern house with tons of windows, while utilizing cisterns/grey water systems/solar/window power.   The lack of mass around the house will require heating/cooling either via propane or other means, and hooked into the grid as a backup, and for feeding excess back into the system.   Something more like below, either way it’s our goal, and we’re no where near ready, and have years to figure out our plan.


I love cob homes as well, but they’re a lot of work.  Either way, I won’t abandon my dream of living in a self sufficient house, even if it’s 10-20 years down the road.   With weather patterns changing, and droughts becoming a norm, I think it’ll become a lot more popular, and hopefully cheaper in the future.


My Obsessions: Electric Cars

August 1, 2015

GM Hy-Wire

I should start off by saying I was never a car enthusiast, in fact I still think auto racing is nothing but noise pollution.  My fascination with electric cars sGM-HyWire_Concept_2002_1024x768_wallpaper_16tarted in 2002 when I read an article on a new concept car by GM called Hy-Wire, which was an electric car powered by Hydrogen.  The car used a delivery system often seen in fighter jets called Fly by Wire.    The cavernous storage space due to the skateboard chassis and lack of combustion engine peaked my interest in the beginning, as I learned more about the Drive by Wire system I became increasingly fascinated.   The Hy-Wire got its name due everything being controlled electronically, so the steering/controls can be move to either of the two front seats.

My interest may have been because of just how un-car it was, it had no brake or gas pedals, the car’s steering wheel was more similar to a game controller, with everything built into the wheel.   I followed the progress over the years, and heard they were building a consumer car based on the technology.       Unfortunately, the car that ended up getting developed was so far from the Hy-Wire that I question if they borrowed anything from the car.


Chevy Volt


The Chevy Volt was the car I had heard was spun off from the Hy-Wire concept car.   It’s an electric car, but uses a combustion engine to charge the batteries.   I started following the volt’s progress right around 2007 when the concept car was released, everyone loved it.   The car looked menacing, and pretty damn cool, unlike most hybrid’s on the market which generally all look the same in order to get the least drag, and thus use less gas.  Little did anyone know however, the end result would be nothing like the concept, they got everyone interested by showing the concept, then completely redesigned the exterior in order to produce the least amount of drag possible.   The end result is the car we see on the road today.

When I found out the engine compartment was now consumed with a combustion engine and the skateboard chassis was awol, I was disappointed to say the least.  However, true to the core, it was still an electric car, and the combustion engine was only used for long distance trips.  At the time it made sense, battery tech wasn’t where it is today, so I conceded, and became slightly obsessed with their success.


Not long after the Volt went on sale, Tesla popped onto my radar.  I followed them but not fanatically early on because of the cost of the car.  One of the first things I heard about the company was how they took used laptop batteries to build their battery packs, I’m still not sure how entirely true this was.  But it’s what got me interested, I loved how they didn’t go the conventional route.

When they announced the three car phase ending with a reasonably priced car in 6-8 years, I started following them much closer.   To me Tesla felt like a company shunning everything done in the last 100 years, and hired bunch of computer geeks to build a car that today’s generation would want to drive.   The end result is the Model S, which is debatably the most beautiful car ever produced.   I feel like it came full circle, and the Model S is a beautiful version of everything I loved about the Hy-Wire.

Like the Hy-Wire everything is built into the floor of the car, thus making it virtually impossible to roll over and the weight and high grade chassis made it indestructible in accidents.    Everything about this car is absolutely beautiful, unfortunately I’ll never own one as its way outside my price range, but the Model 3 announced in 2012 for sale in 2017/2018 is where I’ve got my sights set on.


Interior Dash

Interior Dash


Model S Skateboard Chassis

Entertainment, Food & Wine, Trips

Seattle Weekend ’15

July 28, 2015

We had planned this trip since our Arcade Fire weekend in Seattle in ’14.   We had threatened to do a Blue Jays series in Seattle with my Dad and Carla for awhile since my Dad is a huge Jays fan, but the days just never worked out.   This time we started planning early, so the condo/Jays tix/reservations have been booked since January.   We wanted to balance downtime, with getting to see more of Seattle.   The rundown of our trip is below, I feel like we balanced it out fairly well.    Luckily we live close by so we can always check out what we missed next time.

Day 1:

We left at 9am, and got to the border by 920, luckily we got a crossed the border within 20 mins, and into Bellingham by 1030 so Desiree could have her traditional Clover @ the Guide Meridian Starbucks.

We hit the road, and arrived in Seattle by 1230 for our tour of the Starbucks Roastery, and lunch at our favourite (thus far) Seattle Restaurant “Serious Pie”.   Desiree had been at the Roastery once before, but the rest of us had never been.   It was interesting to see the process of how the coffee is made from start to finish even if I’ll never be a coffee drinker.  The last time we were in Seattle for the Arcade Fire concert we hit the Serious Pie on Virginia after seeing it on one of Anthony Bourdain’s shows.   So we vowed to make another trip this round, luckily one of the three Serious Pie’s in Seattle is inside the Roastery.   While we were there Tommy Douglas was at the table next to us doing some schmoozing, and signing books.



19870873528_01b81ced25_zIMG_20150724_140641Screenshot from 2015-07-26 19:26:04Screenshot from 2015-07-26 19:24:43



When we finished we had nearly two hours to kill before our 4pm check-in, so we drove down to Pike Place to kill time.  I have gotten better with crowds, I no longer feel anxious being sardined in with hundred’s of people in confined areas, and Pike Place definitely proved my new found skill :)    As always I lost Des half way through Pike Place, but we met up near the end, I don’t know how we survived without cell phones.    We went to Pike Place last year, its much like Granville Island, mainly over priced junk, you just go for the experience and say you’ve been there.

We arrived at the Condo at exactly 4pm, Des went in to grab the garage key, and found a room there wasn’t clearly not only cleaned, but the previous tenant’s obviously didn’t bother to do any straightening on their own.   We never leave a condo/hotel etc dirty when we leave it, I would just feel guilty otherwise.  We stayed in a two bedroom ondo at the Modo Apartments on 3rd Ave, last year we stayed at a once bedroom suite on 2nd ave.  It wasn’t a bad experience, just an unfortunate start to the trip.  The room was directly above the bus stop which was great for convenience, but it meant couldn’t leave the window/door open.

We reserved a parking spot at CenturyLink Field acrossed the street of Safeco, while it ended up being convenient and a short walk.   The nightmare getting in/out made me regret the choice.  We thought we were giving ourselves ample time to get there, so we could spend over an hour checking out the Stadium, but the traffic down wasn’t pretty.    We arrived at lovely Safeco Field at 630, we quickly found our seats, then went to find an ATM.   We browsed around for food, Desiree and Mallory had crab fries, and garlic fries, and I had a BBQ poboy and yam fries.  Unfortunately we missed the first inning, and the food was sub par, I should have stuck with the traditional ball  park smokie.


The seats were great, the game started off well for us, and quickly soured by mid game.   It felt like 50% of the fans there were blue jays fans, they were everywhere and very vocal.   I felt bad for the Mariners fans having to put up with us obnoxious Canadians.  The environment helped ease the pain of the loss, Safeco is a beautiful stadium.

IMG_20150724_220212 IMG_20150724_205734 IMG_20150724_205729 IMG_20150724_194851


We realized near the end of the game it was fireworks night, so we stuck around until 1030.   Deep down, I thought it was going to be kinda lame, but I was pleasantly surprised, and it turned out to be really quite fantastic.    The fireworks were synced with music, along with the lights in the stadium to be quite a little surprise after the game.


IMG_20150724_222504 IMG_20150724_221817


20064191781_073867e84a_z 20058862115_d541c9383e_z

Day 2:

We mixed it up for day 2, and parked the car for the day, and walked to WestLake Station to catch the light rail to Pioneer Station.  Unfortunatley,    I’m starting to associate Seattle with pee, I feel like Vancouver has a bigger homeless problem, but I almost never smell pee in downtown Vancouver, but you can’t walk down a block of Seattle without getting a potent whiff of pee, and its normally always around parking garages, bus shelters or pubs.   I had a bit of anxiety about missing our train, but it all worked out and we arrived at Pioneer Station with ample time for our Underground Tour at 11am.

Screenshot from 2015-07-26 21:17:06

We had a reservation for the Seattle Underground Tour for 11am.   The true ground level of downtown Seattle is about 15 feet lower then you see today.  Over several decades in the late 1800’s they built up the city to prevent flooding.   It was fascinating to learn about the history/development of Seattle, and how sewage, flooding, fires, and prostitution helped develop the Seattle we see today.


Looking at the Sidewalk from below the street. There’s not many of the original side walks left, but they built them this way to help brighten the stores etc before the street before there was electricity.

Screenshot from 2015-07-26 19:02:03

Rat problems caused them to close off the underground stores.

Screenshot from 2015-07-26 19:11:51  Screenshot from 2015-07-26 19:02:27

Our tour ended at about 1230, and we made our way back to Pioneer and caught the light rail to Stadium Station, and walked to the Stadium.  We arrived with 20 mins to spare, and this time we grabbed some tried & true stadium food, and got some Nachos and a Smokies and made our way to our seats.

Desiree did a fantastic job picking our seats this year, yet another great view of the field, directly behind the Blue Jays bench.   It felt like a bigger congregation of Blue Jays fans, and there was one really annoying drunk guy behind us constantly taunting the Mariners fans.   I was secretly hoping someone would thump him.   The Jays came out strong in the 2nd for three runs but the Mariners always had an answer and chipped away with runs in the first four innings.   Before we knew it we were down 5-3, and Jays weren’t playing well.   That all changed in the 8th inning when Carrera came up and tied the game with a swing of the bat to make it 6-6.  Des was thrilled to see Sanchez in his first game back from injury start the 8th, and still throwing consistent 99mph pitches.  The Mariners brought in Rodney who traditionally tanks, and he loaded the bases with none out,  Colabello singled bringing in two runs, and the Jays went on to win 8-6.

IMG_20150725_135936 IMG_20150725_134713



Sanchez’s first game back


After making our way through the maze of people, and losing Des/Mallory for 10 minutes, we made our way to the Stadium station, and took the sardine fest back to Westlake Station.  We hung out at the condo for a few hours, and went out to catch our 710 bus to our Dinner reservation at Toulette’s Petit.  Unfortunately we didn’t know it was the night of the Torchlight parade which created a log jam on our street, resulting in  30 min delay of our bus.  Luckily the restaurant held our reservation, we arrived at 8 for our 730 reso.   Toulette’s is a Creole restaurant, primarily specializing in Southern French cuisine.    The meal was great, I’d probably give it an 8 out of 10, I’m spoiled with the lovely food Desiree always cooks so it felt like a home cooked meal, but I didn’t order anything out of the ordinary like Des/Mallory.

IMG_20150725_205111 IMG_20150725_205106 IMG_20150725_201637


19872151889_6b36141ff6_k 19872153129_8d3a6df9a9_k 20050960142_3c8a724656_k


Day 3:

We wrapped up our trip by doing the one and only thing Mallory wanted to do on the trip,  hitting a stored called Kinokuniya.   They specialize in selling Manga/Anime, and various other things.    Mallory was in Manga/Anime heaven and we spent over an hr in the store, and $140 US later, we left for Bellingham.

Screenshot from 2015-07-26 21:28:48

We made a few stops in Bellingham to grab some booze, grub (five guys) and random supplies, and made our much anticipated final stretch home only to find out there was a 2 hr wait at the border as everyone and their dog was apparently coming home from the Jays series at the same time.   I thought it was odd that Trader Joes was so busy with Canadians since our dollar is so lousy, but now it made sense.

The weekend was deemed a success, and I think everyone except for Mallory is looking forward to the next Blue Jays weekend.



Retro – Morris Clan

July 15, 2015

I was digging through some old photos, and thought I’d share them for archival purposes, I’d hate to eventually lose them.


My grandfather on my Mother’s side, Grandpa Offless:


Posing next to my Dad’s nova.


Camping when I was youngin, and busted eating Dog biscuits.


My brother and I hanging out at the campground in ’79


My brother, and I, and my Grandpa Morris.


My first Tiger-cat game against Ottawa around 89 or 90.


My brother and I use to play broomball, the kids league only lasted a year or two unfortunately.


In grade school we use to have hobo day, where you got to dress up like a hobo, I was taking a photo with Trevor dressed up for school.


My turn to dress up…



Garden – 2015

July 12, 2015

Canoeing, Outdoors

Canoeing – Widgeon Creek

August 12, 2014

We haven’t gone canoeing in years, in fact the last time we touched foot in a canoe was around 14 years prior. We’ve wanted to get out in the water for a while now. We finally bit the bullet, and drove to Pitt Meadows on our vacation and rented a Clipper from a canoe rental facility at the Grant Narrows.

I had canoed Widgeon about fifteen years ago with a couple co-workers from my previous employer, and remembered the fantastic scenery and have always wanted to take Desiree on the same trip. It turned out to be perfect weather, not too hot or cold. The walk to the falls was a little longer then I remembered it, but the canoe trip was as calm, and relaxing as I remembered it. The trip solidified our ambition, and plan to buy our own canoe next summer (2016).

Entertainment, Music

Arcade Fire Weekend

August 11, 2014


Seattle Success! Arcade Fire at the Gorge… probably one of the most scenic venues I’ve ever been too, but likely not worth the drive for the venue alone.  However, Arcade Fire definitely made the driving worthwhile with an exceptional set. We also finally hit Serious Pie after drooling over the food on Anthony Bourdain’s: No Reservations several years ago, and now sits in my top 2 for crust, and top 1 overall.

We had a great time in Seattle and will definitely be planning another trip next year for the Blue Jays series.


10467132_10154582811610227_1686978953688484722_o 10580827_10154582811800227_3263674611290179853_o 10453089_10154582811555227_370312091107709350_o 10571951_10154582811795227_5447966963537006056_o 10443193_10154582811440227_4215564267708144694_o 10522375_10154582811775227_5275499760862890608_o 1495296_10154584877375227_4075269845060924565_o 1799914_10154584876395227_8437399429652186605_o