I recently ran into an issue with a WPF application that is a continuous operation Kiosk application. The users log in and are presented with a survey. If the Kiosk is ignored for a time period, a timeout occurs and the screen is reset. However, I discovered that when using MVVM light and View Model (context) injection, even though the view is disposed of, the view model is not. This presented itself when a second user was presented the survey after a timeout had occurred, the survey started on page two or wherever the previous user had left off.

Developer thinking
I tried multiple scenarios of inheriting IDisposable and disposing of the view manually. I also tried several ways of clearing the view’s internal context. It was after none of my efforts were successful, I realized that the context was being stored for re-use by the ServiceLocator and could not be disposed of by the view.

Wait a minute… Inversion of Control… The view should not be able to control the view model. It’s working exactly as designed.

How does it get there?

Normal MVVM Light injection takes place from a ViewModelLocator class that is declared as a resource in the App.xaml. There is plenty of documentation of MVVM Light framework on their website, so I won’t go into the details of setup. But, in a nutshell, the view has its context injected in the XAML page as an attribute like so:

DataContext="{Binding Source={StaticResource Locator}, Path=SurveyPage}"

The path corresponds to a method in the Locator class which returns an instance of the view model from the service locator if one exists or creates a new one if not present.

 public SurveyViewModel SurveyPage
                return ServiceLocator.Current.GetInstance<SurveyViewModel>();

If an instance doesn’t exist, one is instantiated during the InitializeComponant() method of the view. However, here is where the problem arises. If you dispose or close the view in normal operations, WPF disposes all of its internal resources associated with the view, but the instance of the view model remains in the ServiceLocator container.

How to clear out the view model

After a fair amount of unsuccessful research on the Google box, necessity (panic?) presented a really simple solution. As one would expect, closing the view fires the build in Unloaded event. Here is our jump in point. Our Locator class is a static method, so the simplest solution was to add a method to unregister and re-register the view model. As I was happy to find out, this cleared the model from the container and registered a new version. Since the container did not have an instantiation of my view model after the unregister process, the next time my view ran through the InitializeComponent () method, Bingo! A new view model is instantiated and injected as context for the view. Here is the very simple method I created to remove the view model:

public static void UnRegisterSurveyViewModel()
And I simply call it from the unloaded event:
private void MyView_Unloaded(object sender, RoutedEventArgs e)

We all know the web is big, but how big is it? Worldwide, a LOT of people are using the web, but how many? I wonder things like this from time to time. Occasionally I like to dig into the stats in hopes of better understanding this World Wide Web that I work, play, and depend on (sometimes regrettably) so much. I recently found answers and noticed some pretty interesting trends and some important stats, and I wanted to share those with you.

Stats of the World Wide Web

world wide web image


Over 3 billion worldwide internet users were reported in 2014 by internetworldstats.com


The official number reported was 3,035,749,340 and that’s about 42.3% of the total world population. At the turn of the millennium there were only about 361 million users worldwide, so there has been a 741% growth rate since then. Clearly, mankind has fully embraced the internet.

Asia statistic image


46% of worldwide users access the internet from Asia


This more than doubles the next best continent (Europe 19.2%), and leads the world with over one billion users. The official number of users reported in Asia is 1,386,188,112, which is a 1,112.7% growth rate from the year 2000. Although Asia leads in total number of users, only 34.7% of the population uses the internet.

North America stat image


88% of North America’s population uses the internet


The percentage of North Americans that use the internet is more than any other continent (followed by Australia/Oceania at 73%). North America only has 10.2% of internet users worldwide, however, this statistic suggests that they rely more heavily on the internet from day to day. North America currently has approximately 310,322,257 users which has seen a 187.1% growth rate since the year 2000.

Stats of the Mobile Web

mobile web image


Over the last five years there has been an increase of 5,538% accessing the internet from a mobile device


In 2010, 13.98 million people in the world were accessing the internet via smartphone or tablet. That number is projected to be 788.32 million in 2015. This trend speaks to the importance of providing all content to all devices so that mobile users are able to access information and perform activities without restriction.

smart devices shipping image


An estimated 1.3 and 2.4 billion smartphones and tablets respectively are projected to be shipped globally in 2014


Yeah people use these devices a lot, or have you been under a rock? I think I even seen one guy’s hand growing around his phone as if it was an appendage. These popular devices are a mega hit and aren’t
going away anytime soon.

Interesting bathroom stat image


75% of American’s bring their phone to the loo


That’s right, we American’s can’t resist multitasking and executing a tap-pinch and swipe while using the bathroom. 63% said they have received a call while handling their business, and 41% said they initiated the call. It is safe to say that American’s take their phones with them EVERYWHERE.

The big bad internet is growing rapidly and we have to keep up. I hope these stats help you think about your business and your online presence. At this point, if your site or application isn’t mobile friendly then you are behind the eight ball and you should devise a plan to address it immediately. The professionals at Mercury can help you with that 😉


Scrum can be a great approach to software development, however the focus of this article will not be on the many benefits of Scrum. Instead, let’s talk about what it takes to get there. Beyond the mechanics of sprints, backlogs, stories, and tasks there is a much harder to account for requirement for Scrum. Trust. Trust between team members is an absolute necessity. Without trust, scrum can quickly turn into one headache after another.

There are many levels of trust that must be developed in order to have a truly effective Scrum team. You must have trust among individual team members, between the scrum master and the team as a whole, and between the product owner and the team as a whole. Scrum may work with some of these elements missing, but it can work so much better with them present.

Trust as a Concept

Trust between Team Members

Individual contributors must be able to trust each other. When individuals do not trust their team mates you can end up with a variety of troubles including:

  • Duplicate work – individuals do not trust that the other will complete their work in a timely manner and they may attempt to complete portions of their work in order to allow their own work to continue.
  • Micro-managing – individuals may not trust in the quality of the work their team members produce and may spend too much time correcting each other to get their own work done
  • Blame passing – rather than working together to resolve problems, individuals who have not built trust in each other will seek to blame others which will further degrade the relationship.
  • Lack of communication – team members that don’t trust each other will not be able to communicate openly with each other. They fear being shamed in front of other team members and will struggle with problems that another individual may have a ready answer for.

Even if all of the proper scrum protocol is being observed these issues result in poor quantity and quality of completed work as well as a poor work environment for the entire team. The initial thought may be that it is entirely the individuals involved that cause the problem in this case, but while that can contribute it is often not the whole story. These behaviors can be caused by a variety of external factors.
Poor Evaluation

  • Emphasis on individual accomplishments rather than team achievements can cause resentment or an overly-competitive team. Concentrating on the team’s progress makes sure that it is in everyone’s best interest to help their team mates succeed.
  • Lack of safeguards to ensure quality work can cause uncertainty around the work being produced. Having tools like automated unit tests, code coverage, and code reviews can help the team trust that their team members are creating a quality product. It is, however, important that such tools be applied equally to the team as a whole. Singling out individuals will only increase trust issues.
  • Lack of a forum for open communication can cause team members, especially introverts, to feel like they do not have a place where they can express concerns. This should be accomplished with the daily standup, but people often feel constrained to giving a status update and no more. It is important that any possibly relevant issue be given a chance to be aired in standups. It is also important that ideas brought to such a meeting are given true consideration. If people’s ideas or concerns are dismissed too easily, they will stop bringing them up. While it should be the job of all team members to ensure this is happening, the scrum master should be responsible for setting a good example in this arena.

Trust between Team and Scrum Master

A scrum team that does not have bidirectional trust between scrum master and the team of contributors removes all benefits of having a scrum master in the first place. If a scrum master cannot trust the information provided by their team or a team cannot trust a scrum master to do what is best for the team, then this dysfunctional relationship will grow into a much larger issue.

  • Padded estimates – if a team does not trust their scrum master to take their estimates in good faith, then they may add additional and unnecessary padding to story/task estimates to guard themselves against being reprimanded. If a scrum master does not trust the estimates provided by the team they may pad or reduce estimates without consulting the team.
  • Lack of commitment – if a team feels like there is a chance that their commitment to completing their sprint work will be abused by the scrum master allowing additional work into it without taking proper balancing actions, they will be less inclined to take their commitments seriously. If the scrum master expects the team to not meet their commitments they will be more likely to practice bad sprint hygiene.
  • Poor communication – if a team member does not feel that their scrum master has any power to help they may be less willing to go to them with concerns. A scrum master that does not get all the information may communicate poorly with the product owner or other stakeholders.

A team that does not take their commitments seriously will result in disappointing sprints that do not meet the needs of the product owner. It is important to note that this is a two way relationship and changes may need to be made on both sides to gain this trust.

  • Team members that feel empowered to reject a change that the scrum master is making will allow the scrum master to learn to make better decisions for their team and will make the team feel like they have a say in how to interpret their commitments.
  • Scrum masters that show understanding when an estimate is incorrect are more likely to get truthful and useful estimates from their team.
  • Scrum masters and team members need to be honest about what they can accomplish. It is easy to let optimism or ego make you promise things you can’t do.

Trust between Team and Product Owner

The levels of trust required between a product owner and a scrum team are very similar to those between the scrum master and the team and the problems caused are very similar. If a team does not trust their product owner to be fair and considerate then it will be very hard for them to be honest and upfront with estimates and commitments. While the results of this distrust are similar to the scrum master to team relationship, the causes and approaches to resolution are a bit different.

  • Product owners who are further removed from the scrum process may not understand or value the iterative process. This can cause the project to revert to a more waterfall approach thereby negating many of scrums benefits. A product owner needs to be onboard with the scrum process and allow it to work.
  • Inflexible team members can cause a product owner to lose faith that their changing needs will be met. Ideally every sprint would turn out exactly as it was planned, but not everything works out that way. Team members and scrum masters need to be willing to work with the product owner to get everyone what they need.
  • Product owners need to be understanding that sometimes communicated requirements are not sufficient. The team is going to have questions and will need access to someone who can answer them. A lack of availability on the product owner’s part can result in a team that is not confident in their ability to deliver the right product.

Scrum as a whole is all about trust; trust in the team, the leadership and the process. Without this you are fighting an uphill battle. Trust is unfortunately not the easiest thing to build and all the team building activities in the world are not going to fix it, if the team cannot apply it to the day-to-day scrum process. Trust is built over time by making commitments and keeping them and by thinking about the team first.