Locally testing a self signed SSL certificate in IIS manager and getting “The process cannot access the file because it’s being used by another process” error

Making changes to our shopping cart for Google Analytics, Conversion, and eCommerce tracking. In order to test a local version of the shopping cart I had to make and use a self signed SSL certificate.


2014-11-28 21_39_57-Clipboard

Every time I try to start the site “learning2” with the binding to port 443 (https) in IIS Manager I get an error message:

You receive a “Cannot Start Web Site” error “The process cannot access the file because it is being used by another process” error message when you try to start a Web site in the Internet Information Services MMC snap-in

2014-11-28 21_41_05-Clipboard


Reason and Resolution: Another process is using port 80 or port 443 on the computer that is running IIS. By default, IIS uses port 80 as the default TCP port and port 443 for Secure Sockets Layer (SSL). In order find out what’s using port 80 and 443, for HTTP and SSL respectively, you would enter this at the command prompt:

netstat –ano | find “:443”

netstat –ano | find “:80”

2014-11-28 21_41_32-Clipboard

In the output see the process ID “9820” for localhost using port 443? Next start windows task manager and look at the “Processes” to find out the culprit. You might have to turn on the PID column to see it (view->select columns). For me it was Skype that showed up as the process that matched the process ID “9820”. After turning Skype off entirely, I was finally able to start the site that was bound to port 443 in IIS Manager. Hope this article helps anyone else getting stuck on starting up a site in IIS. It could be a number of other programs using the ports so the best thing to do is check using the netstat command and matching up the PID with what you have in Task Manager.

Here’s the Skype setting that was causing the issue (Tools –> Options –> Advance –> Connection) see below. You could also leave Skype running and just turn off the ‘”Use port 80 and 443 as alternatives for incoming connections”. Remember to restart Skype to propagate the settings.

2014-11-28 21_42_17-Clipboard


Shortening the feedback loop: phone interview

Been a while. Here’s a podcast about the book contribution the team and I worked on last year. The topic of that write-up was “Shortening the Feedback Loop” and hopefully it will be published soon. I only had 15 minutes to prepare for this interview so it kind of caught me off guard. I definitely have some room for improvement on my phone interview skills. Oh well, that’s the way things go sometimes… “you know!!”… http://www.blogtalkradio.com/rapidbooks/2011/04/04/agile-stories-retrospect

Functional Testing Tools

The need for acceptance testing has become too important to our product and is now included in our automated build environment (more info on automated build environment here). While Test Driven Development (TDD) does produce good quality on the specification of the requirement from the component side, it doesn’t adequately target “how the system” should act from the end user perspective. There’s a lot of UI specific tests that need to be performed on the views to ensure that the correct functionality is doing what it was intended to do. In an agile development environment, like Extreme Programming, these black box system tests are known as functional tests which tests the validity of a user story; as opposed to unit test which tests the verification of a specification (written TDD test-first style in our office, which helps but are still from the point of view of the developer). On the other hand, functional tests can be written by testers, business analyst or the developers, but since they are from the perspective of the end user, or subject matter expert, they are best written (or at least specified) by the business analyst. During the teams research we wanted to find a tool that can be integrated into our environment as well as easy enough for a business analyst to write.

Here’s a resource to the 4 testing quadrants as identified by Janet Gregory. Image taken from http://agilevancouver.ca/sites/agilevancouver/files/speakerslides/Vancouver-Quadrants.pdf

agile testing quandrants



Here’s a list of functional testing tools identified by Gerard Meszaros and added to by others in the industry . These functional testing tools focus mainly on the 2nd Quadrant above.

The one I am currently trying out iTest2, basically uses Watir under the hood but includes a nice IDE (actively being developed) and an abstraction on top of Watir called RWebSpec. It’s easy enough for the business users to add functional tests (especially if they’re using the recorder), but complex enough for when the developers/testers need to access to the COM interfaces which gets at the browser’s document object model, DOM, without need for directly interfacing with the UI. So far this tool is starting to prove itself but we’ll need more time to see if it is the most effective one out there.

Things still left to do:

  • Include functional tests as part of our story breakdown planning and estimating process (Example here and they can act as requirements artifacts/documentation).
  • Try out StoryTeller as a solution to automated acceptance testing in .NET.
  • Assess how we’re doing in the 4 testing quadrants (above), then alleviate any shortfalls.
  • Figure out how the database gets loaded with information from our functional tests and how tests can be independent from each other (test servers, scripts).
  • Move to a better functional testing as compared to plain old record/playback because it can become cumbersome to maintain.
  • Stay on top of software testing as the advancements in this area are changing daily http://www.testingreflections.com/

Getting Real – The smarter, faster, easier way to build a successful web application


getting real book_3

I decided to pick up this book after the PDF was recommended to me by my boss and president of the company. I’ve always heard of 37Signals and their slew of online products (I even use some of them today). And of course in the development world who hasn’t heard of Ruby on Rails, created by David Heinemeier Hansson, who is a partner at 37Signals. This book was written by them after their experience in the IT startup world and after successfully developing some really cool web applications.

Overall I like the way this short book takes a lot of agile and lean concepts and applies them in the real life of a startup company. It’s even written in an almost point form sort of way, giving you little “lessons learnt”, “how we did it”, and “what we think of that topic” in very short 1 to 3 page sections. Although the content is very quick and to the point, there’s definitely a lot reference to background information alluding to why they think or do things a certain way. From industry cases like that of Steve Jobs to references from the Pragmatic Programmer you can really see the depth of understanding that these guys have for the values and principles which also stem from lean and agile frameworks. This book really shows a reality that can be achieved using the efficiencies brought on by adopting agile and lean values and principles.

Here’s a list of points that stuck out to me while reading this book:

“Scratching your own itch” – Open source developers find it easy to build solid high priority features because they are their own users and will build it when they need it. When you solve your own problem you create a tool that you’re passionate about.

“Constraints force creativity… and drive innovation” – Limiting your resources makes you deal with the most important things first and helps get your product out the door quicker. It also helps you get feedback on your product sooner. Work with what you have.

“Allow emergence” – Simple rules can lead to interesting complex behavior, cultivate an environment built around simple rules and allow for emergent behavior.

“The devils in the details” – Details reveal themselves as you use what you’re building. You’ll know which potholes to pave over because you’ll keep hitting them. Don’t waste time on problems you don’t have yet. Pay attention to the details when they matter.

“Avoid preferences” – Preferences and user options create more code, tests, maintenance, computational complexity, complex usability etc. You make the decision so your users don’t have to on the defaults. Make the best guess and move on.

“Be an executioner” – Ideas are just a multiplier, they are worth nothing unless executed. Execution is worth millions.

“Alone time” – People need uninterrupted time to get work done. Set aside half a work day where interruptions are  This one is a hard one because it’s so hard in our open workspace; interruptions come easy from both inside the team and outside.

“Innovation comes from saying no”  – Make each feature work hard to be implemented. Listen to your users but don’t act hastily. Say no to all but the crucial features. You’ll know what they are don’t worry.

“Can you handle it?” – Build products and offer services you can manage. It’s easy to make promises, but much harder to keep them.

“Promote through education” – Education is a soft promotional technique. Share your knowledge with the community and at the same time promote your product or create a positive buzz with your users. People you educate will become your evangelists.

“Beware of the bloat monster” – Resist bloat. Just because the application is older and more mature doesn’t mean it needs to get more complicated. And new doesn’t always mean improved. You don’t need to up-sell by constantly adding more features, you just need to provide ongoing value.

Definitely a short reading to share with your team! So, I am passing this one on now.

Visit from our Angel…

Last week we had a visit from our Angel Investor, Greg Olsen, of GHO Ventures based out of Princeton, New Jersey. He helped eCompliance get off it’s feet 2 years ago. He brings with him an astronomical (pun intended) amount of experience and wisdom that really differentiates us from the other startups in our field. It’s exciting to know that we have support from an accomplished entrepreneur with a wealth of business experience to motivate us along the way.


Greg Olsen Visit 2009-07-15_thumb

Our entire team met with him for a few hours and mainly talked about his experience as the third private citizen to go into space. For guy with so many credentials and accomplishments, he’s really down to earth! Truly inspiring.

We Want You!


We want you eCompliance_thumb

We’re looking for passionate and talented Agile .NET Developers! Here’s the details:

eCompliance Management Solutions Inc.
eCompliance Management Solutions Inc. (eCompliance.ca) is the leading provider of Occupational Health & Safety (OHS) Management solutions in Canada. eCompliance.ca is a privately held company with its head office based in Calgary, Alberta, Canada. eCompliance.ca focuses on making use of the latest technological advancements to build practical and cost effective solutions for its customers and is the preferred technology partner of Canadian organizations in OHS by providing efficient and effective practical solutions to measure, manage and mitigate Health & Safety Risks in the quest for ‘Zero Incidents’.

The Candidate

  • You are looking for an exciting and rewarding career using the latest tools and technologies.
  • You are highly motivated and passionate about developing software that impresses your colleagues as well as the customers you are building it for.
  • You are a software craftsman who wants to make a difference both in the software industry and the domain in which you work.
  • You believe that the ALT.NET movement will change the development industry and want to be a part of it!

Skills and Qualifications
Must Have

  • Post secondary degree in Computer Science or similar technical training.
  • 3+ years developing applications using C# and .NET Framework.
  • 3+ years experience building large scale web applications using the latest technologies.
  • 2+ years experience with the latest Microsoft technologies as well as open source projects/tools that integrate well with an Agile development environment.
  • Good communication and team skills.

Highly Desirable

  • 2+ years experience with Agile Development practices and working in an agile team using XP and Scrum.
  • 2+ years experience with test-driven development (TDD), object oriented design (OOD), domain driven design (DDD), and design patterns
  • 2+ years experience building windows desktop applications or .NET Smart Clients is an asset.

Additional Perks

  • Comprehensive health benefits package
  • Company Stock Option Plan after 1 year of employment
  • Flexible team work schedule
  • Training opportunities and monthly book allowances

Bottom Line
This is an opportunity to work in a fun and collaborative environment where a ton of learning and contribution to the development community is supported. If you are or want to be a top-notch .NET developer then this is the place for you!

Please submit your resumes to careers at ecompliance .ca  attention Luu Duong (let me know that you saw this on my blog). Candidates must be Canadian citizens or permanent residents living in Calgary area.

For more information ‘About Us’ please visit www.ecompliance.ca

Applying the "80-20 Rule" with The Standish Group’s Statistics on Software Usage

What’s 80-20 rule?

Also known as the Pareto Principle, the law of the vital few, and the principle of factor sparsity, states that, for many events, roughly 80% of the effects (output) come from 20% of the causes (input). In the early 1900’s it was observed by an Italian economist Vilfredo Pareto, that there was an unequal distribution of wealth in his country where 80% of the land was owned by only 20% of the population. While originally pertaining to economics, this phenomena was observed by other professionals in their own areas of expertise.  In business for example, 80% of your sales come from 20% of your clients. In the software domain, many experts note that if you develop 20% of the highest priority features, you’ll satisfy 80% of the business needs. Moving on…

What’s The Standish Group’s statistics on software usage?

Jim Johnson, Chairman of Standish Group, reported at the Third International Conference on Extreme Programming (XP2002) that in typical software systems 64% of features are never or rarely used in reality. This was largely apparent in systems where up-front plan and design were done before business ROI was considered or even knowable. What’s more interesting is that from a positive point of view, 20% of these features are used always or often used!

Merging the two to get the highest return on investment for the business!

So, it should follow that if we can prioritize our requirements (stories) and work on the most important 20% of our backlog (list of epic stories), then we could ultimately satisfy 80% of the business needs. At the same time; once this initial 20% of the features are in production, it will also be used by the business predominantly (always or often). The most important part of doing this effectively is finding that initial 20% of the requirements that return 80% of the clients satisfaction. An valuable Product Owner will be able to prioritize and understand that not every feature is high priority. I believe that the more you understand your business, the easier it is to arrange your priorities. That’s why an effective PO is the foundation of delivering valuable business features.

In Practice:

I’ve witnessed the 80-20 rule apply itself over and over again in our industry and also in my position. Software products developed where an equal amount of effort was put into building low priority features as it was to build the high priority features. At the end of the day, the return on investment was inherently lower on those features which customers rarely or never used or were unimportant. Effort is lost or wasted, which could have been allocated to more important features or features that that will be used more often. If you’re working on a project with unlimited budget then this could be OK, but I’ve yet to see one in real life (nor do I ever expect to).

This is not to say that any feature that is not used often or always is unimportant. Sometimes a feature that is used rarely is important to the business; in that case the priority would be high and likely moved up the priority list. But more often than not, if a feature is used often or always, it is likely to be a higher priority feature versus features that are used rarely or never (obviously). The better the Product Owner, the more fine grain each priority will be.

My humble advice:

If given adequate time on a project, module, or epic story, by working on the highest priorities first, as soon as you reach the most important 20% anything after that is bonus. Continue working on the time-boxed iteration or release plan, delivering beyond the initial prioritized 20% if you can (reach 55%), but remember that your effort-to-results ratio will diminish dramatically the further you go to fulfill 100% of the features. You could move on after the initial 20% to another important module, or work until the time-boxed iteration (fixed amount of money) runs out. A good idea after building the initial priorities is to stop and get feedback. Feedback is a time for the business to learn and for the development team to adjust if necessary. I can almost guarantee that the business will ask for something else that they originally didn’t plan to or have other opportunities come up that change priorities for what is important now.

Focus on the 20% that matters:

It’s not to say that the other parts of the software are not important, but that you’ll get more return for your efforts if you focus on the most important 20%. Here’s an example of how this works:


By working on the highest priority features first, and releasing early the customer has an opportunity to learn from the market (2 pre-releases occur before the project release date). Also the business has a chance to realign it’s next priority needs if necessary. The highest prioritized features are delivered earlier in the project, usually before the project is over or the money runs out. These features are the ones that will be used always or often by the business. An added bonus is that the company can actually start making money (earlier than expected “$” shown on the diagram) during these initial releases. As a consequence the software is bringing income into the project allowing it to partially fund itself. I’ve witnessed many projects partially funding itself first hand so this is not a hypothetical situation. If time/money does run out before the entire product backlog is complete then you’re still in a good position because you’ve already met at least 80% (if not more) of the business needs. In the example diagram above, we’ve delivered over 55% of the features. What’s remaining in terms of features are never used (according to the Standish Groups report on software usage). I wouldn’t go so far as to totally ignore the remaining features, but I would agree that they are far less appealing and less rewarding to work on than the initial 55%.

Prioritize and focus on what matters the most, you’ll see more benefits emerge with less effort. Ask yourself the question “What are the priorities and are we working on the ones that we value the most“. You’ll see it applies to many other aspects of life, not only the software business!

Shortening the Feedback Loop – Our Sprint in a Nutshell

Thanks to everyone who attended the 2008 December Calgary Agile Methods User Group (CAMUG) meeting yesterday. We received a lot of questions during the presentation and good feedback after the presentation. Some people asked for a copy of the powerpoint slides, here it is. The slides don’t tell you too much about the actual content of the presentation because most of it was elaborated by the presenter, but it should give you a good idea of the points. Here is the presentation synopsis:

Under the Agile software development umbrella there are many principles, processes, methodologies, and practices that fit this style of development. Many companies are relentlessly seeking and implementing ways to continually improve how they design, develop and deliver software. We believe and have found in practice that the Agile way of software development enables, supports and drives this continuous quest for efficiency and improvement. One of the primary goals of Agile software development is to satisfy customer needs through early and continuous delivery of valuable software. We find that most of the business value comes from creating an environment where a shorter feedback loop allows our team to be more proactive and adapt quickly as and when necessary. In this presentation we will share and walk you through a typical sprint/iteration at eCompliance.ca and highlight to where we have shortened the feedback loop and increased efficiency and feedback quality.

See Mo’s blog for pictures of the audience.

Presentation at a glance:


slides outline

Japanese terms for the Agile developer

If you’re interested in knowing about how Toyota became the world’s most profitable car manufacturer then this book is for you!



For more than 50 years Toyota has applied and refined it’s lean manufacturing principals, also called TPS or the Toyota Production System. Without going into the details of this book (for now) here are some Japanese terms I thought would be very suitable for agile developers and the agile community at large.

Kanban – Card or ticket or sign board. Used to signal to the previous step when its part needs to be replenished. Kanban is a signaling system to trigger action. This creates a “pull” system

Heijunka – Level out the work load. A production scheduling and load leveling tool. Distribute kanban cards in an efficient manner.

Muda – Waste or non-value-add work. Eliminate waste or non-value-add is a top lean philosophy and is said to be the focus of most lean efforts.

Muri – Overburden or pushing beyond limits. Overburdening machines causes breakdowns and defects and pushing a person beyond their natural limits causes safety and quality problems.

Mura – Unevenness. Muda will be a result of Mura. Unevenness results from an irregular production schedule or fluctuating production volumes, indicating internal problems. In lean manufacturing you need to balance production volumes.

Jidoka– Built-in quality. Also referred to as “autonomation”, equipment endowed with human intelligence to stop itself when it has problems. Used as a quality control system to build a culture of stopping to fix problems and getting quality right the first time.

Andon  – Light signals or cords that could be pulled for help. Used to stop or warn the production line in a specific section or work center.

Kaizen – Continuous improvement. The process of making incremental improvements, no matter how small, to add value. Defines Toyota’s basic approach to doing business.

Genchi Gembutsu – Go to the source to thoroughly understand the situation.

Nemawashi – Literally translates to “going around the roots” or closely translated as “laying the groundwork”. Discussions between many people giving input and helps everyone to be in agreement when a decision or change is made.

Hansei – Reflection, become a learning organization through relentless reflection. Hansei go hand in hand with kaizen, without reflection you cannot have continuous improvement.

Hoshin Kanri – Policy deployment. Directing and motivating organizational process by cascading objectives from the top of the company down to the work group level.

Sensei – One who provides mentoring, teacher who has mastered the subject.


There’re probably some more Japanese terms in this book that I missed but these ones stood out to me the most. I see many resemblances to Agile Software Development thinking, processes, methodologies, etc. in the terms above. Can you do the agile translation of the of these Japanese words/phrases?