Browsing Category



Our new wheels

October 25, 2020

As many of you are aware I’ve been kinda obsessed with EV’s for years, and always vowed to one day have one. We’re a one car family and were waiting to buy an EV that wasn’t Model X money but still fit our lifestyle. Once we got our trailer that made things more complicated so we vowed to wait it out for the Rivian R1S or Cybertrk.
The R1S was above what I wanted to pay and the Cybertrk was way too big, but fit all of our other criteria. I reserved it the night it was unveiled as a backup plan in case nothing else came out.

We recently decided we wanted a better tow vehicle for camping in the interim and after running the numbers I found it was the same cost for us over the long term to have 2 cars with our main car being an EV then it was for us to buy an older Truck/SUV to be used as a daily driver & tow vehicle. We decided to buy a Tesla Model Y as our main car, and later in the spring we’ll be looking to get a 2nd car for towing our camper. I’m also exploring the possibility of renting a truck for the once every 3-4 weeks we go camping half the year.

We had an appt for the showroom on Nov 12th where we had hoped to put down a deposit, and driving our new midlife crisis car by xmas.

Unfortunately becuase of the new lock down put forth two days prior we had to cancel so on Nov 28th, we made the decision to just buy the car without a test drive. With Tesla everything is done via online forms and email. We were contacted on Dec 7th and told we could book a day to pick up our car, we choose Dec 13th. We arrived 20 mins early for our appt, so we did a quick once over on our car in the lot. Paperwork with Tesla took maybe 10 minutes, and ICBC was about 30. We were in and out with our new car in under 45 minutes. Definitely the most painless car buying experience we’ve ever had. We’ve now had the car for 3 months, and still loving it as much as day 1. We went from 300 a month gas bills to a 90 dollar electricity bill, and virtually no maintenance.


My transition to Agile.

August 3, 2015

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