Just as the importance of unit tests during development phase, so is the environment verification test during deployment phase. Environment verification test is the most important tool for an application during deployment phase or even maintenance phase.

An application often makes assumptions about the environment within which it runs. It might requires a file being present, an environment variable being set, or a functioning network environment. Without any of these assumptions holding true, an application cannot run. And depending on the quality of an application, when the assumptions about the environment are broken, it might or might not be easy to find out.

That’s the first part of environment verification test. An application should be robust enough that even when any of its assumptions does not hold it can still behave reasonably. Under such circumstances, an application should gracefully exit and pop up an easy to understand message indicating what the problem is (what the broken assumption is).

The second part is a tool set for quickly verifying the environment. Normally if the first part is well done, most applications do not need this kind of tool set. However, providing such tools could be handy during deployment. First of all, the person responsible for deployment does not need to start the application simply for verifying the environment. The tool should carefully examine the environment against all the assumptions made by an application. It should produce a complete list of all broken assumptions so that the list could be sent to the developers later for problem determination.

Most of the time wasted during deployment comes from the mismatch of the real environment and the assumed one made by the application. If we can quickly determine whether the problem is related to the environment or not, our lives will be a lot easier.

Software That Lasts 200 Years by Dan Bricklin

An idea came to my mind while I was reading this article. Is the idea of operating a company specialized in fixing “all kinds of software problem” feasible? For non-technical users, when their computer is no longer functioning, they call support or help desk from the company where they bought the computer. But what if the company is no longer there? When our televisions broke down, we call some one to fix it no matter what the brand is. If the guy who came to my house happens to be not capable of fixing it, I just try to find another guy from the yellow book. Is this model applicable to software industry? Is this business profitable?

I like talking about software quality very much. It was always a struggle to me that software was all about “hurry upgrade”. Do it in a hurry, and hurry users to upgrade. Who would sell a product which could be used for more than 50 years (OK, 10 years) without any problem (problem brings money)? The company will disappear in 5 years if they keep selling this kind of (perfect) products. But is that true?

When building a software that lasts 200 years is profitable, then it might be the time to make quality first priority. Quality software is never an easy matter, but having such mindset is really important no matter whether we are reaching that stage or not.