While identifying a problem, I always keep the A.C.E model in mind. A.C.E stands for Assess, Contain, Eliminate. Let me explain how the A.C.E model works as a trouble-shooting tool for development testing, after the launch of a website.

A. Assess. Trace the site or application activity from the launch date to the day the problem first occurred. Use any original or back-up data that you have on hand and compare it to the client copy. If there is something that was added or taken out, find out why. It could be a simple solution if the problem stems from something environmental or technical. Find out if there have been any changes (major or minor) in the client’s capacity to host the site or application (i.e. switched hosting companies, bought a new server, etc.).

Also look for any irregularities or errors that would not have come up during testing—things like too many user requests (a common issue in commercial sites or sites for huge corporations). Let the client know that an application or site designed to handle 10,000 unique visitors may have trouble handling hundreds of thousands, since the requests to view and use the site will lead to denial of service.

It is prudent to look at the type of hardware in use to narrow down any problems before and after the launch. We test using the minimal requirements of a site, knowing that if it works using moderate to contemporary equipment, it will work with cutting edge server equipment. Once the problem has been assessed and identified, we move to the next stage.

C. Containment. Whether it’s a small programming bug or a major error, it is the responsibility of the tester to be candid to the client about the extent of the situation. There are numerous factors as to why the bug got past the testing phase, such as not enough testing time, launch was pushed ahead of schedule, or the like. But the fact of the matter is the problem exists, and it has to be dealt with.

A tester would be able to contain the problem and anticipate if the solution could accidentally cause another issue. In this case, the best course of action would be to not take the application or site offline, but to limit outside access to the resource. It wouldn’t make any sense to continue to grant access to something that, in the user’s mind, does not work.

At worst, the application or site would have to limit user access for a few days until everything is corrected and functional. It is in the client’s best interest to welcome user feedback, as this feedback could improve client interaction. Now that there is an understanding of the expectations and requirements of the client, this knowledge can be applied to the next project.

E. Elimination of issues can take many forms but the results are always the same: resolution of outstanding issues and client satisfaction. No matter what the cause, it is important to learn from the recent crisis (and believe me, to the client, it was a crisis). For the next project, the professional will remember the causes of the issue and can take a different approach. In turn, the client can plan ahead and adjust for extra testing and leeway in case of delays.

The goal of research and the A.C.E model is to make sure that anything we do as professionals is up to the standards of our clients. Anyone with the right training can make an application or website and make it look pretty. But a professional will take into account the client’s individual needs, user expectation, and the scalability of the end product.

This methodology and practice, as outlined above, has obvious benefits, such as limiting usage while testing and Q&A occurs, as well as setting client expectations for deployments and quality control throughout a project, as well as during those critical days after launch. The world of software, like many other technical fields, present its own core list of challenges and we aim to achieve the highest level of stability and consistency for the websites we build.

One thing that always bothers me, whether I'm building a computer or doing research for other people, is that people don't always know what they want.

I'll explain. Everyone, including myself, has an occasional moment when they think to themselves, "If I would have known this or found out about that, I would have done (fill in the blank) differently."

And because of this, I approach almost every situation with this in mind: "I don't know everything, but if I did, how would I go about this?" Some of the most common questions we get at Killswitch when it comes to our business (other than "How much does it cost?") is "Can you make it work the way WE want it?", and my personal favorite "I have a site and I want to rework it. What do you recommend I do with it?" Here is where I come in (maybe that's why it's my favorite--it's nice to be wanted).

Let me explain the “Can you make it work” question. There are times where the client has an idea about how a site or application is supposed to work, and while the idea is what counts, the technology they want to use is not suitable to the task. We will try to recommend to the client the right solution; after all we always have our client’s best interest in mind. But what if the client is set on a specific technology? Do you tell the client that they don’t know what they're talking about? Do you risk your reputation on a minor technical disagreement? I say no.

The purpose of the research that we do is to provide simple, specialized solutions--elegant design with the best possible user experience at both the client and user levels. That’s why we spend time researching, scrutinizing, putting together the pros and cons of current and upcoming technologies, and making our case to our clients. Most go with our recommendations; others maintain that their approach is the best. Again, we have our client’s best interest in mind and so, before we begin anything, we inform them of any potential pitfalls and shortcomings that might come up. It’s our professional responsibility to also educate the client, whether they go with our recommendations or not, by putting together help and technical documentation and, when we feel it’s necessary, video how to’s. We do this to minimize learning curves and get users up and running.

And while I’m in an explaining mood, let me also touch on the "reworking" aspect of our business. Let’s say that a client has a website that looks outdated, and they want to modernize it. We can do it of course, but does it have to be from scratch? Can old data be reworked so that information can be re-used? Again, we research ways to save data and rework a site or application to satisfy the client. All we do, aside from updating a site, is give it a face lift, so that the client’s message is seen (and heard) in this multimedia-driven world.

In the end that 's the goal. We want to make a dollar and a dime in this business, but we also want give people something useful, and possibly entertaining, something that will make others say, "This is a nice site or application, it's easy to use, looks great and it does what it's supposed to."

A little research comes in handy in our world. It could make the difference between telling a client that their project will be done on time or that it has to be delayed because there were factors that were unaccounted for (servers not equipped to handle the amount of net traffic, site is too complex for users, etc.).

Information is power, and in our world, it's a necessity.