Jason Boyd's Weblog

Supporting Mission Critical Applications

Fri, 10 Feb 2006 10:38:54 -0500

During the development of a mission critical application, there is a tremendous amount of effort spent on building quality into the application. This effort is justified because once the application is deployed, the amount of downtime or system errors is expected to be minimal. The reality is there will be unexpected application responses or application functions that simply stop working, due to either slightly different data sets or a completely different execution path through the application that the end user has chosen to use. When this occurs the support response to the end user becomes critical to the overall success of the application.

Team Direction

Wed, 02 Nov 2005 09:40:50 -0500

Over the past six months or so I have been helping manage a team of resources that is building templates for a SQL*LIMS implementation. When I was discussing this with a member of a training class I was teaching, he asked how we were able to build all of the templates with multiple distributed resources that aligned to a set standard. At the time I could not give him a very good answer. All that I could come up with was that "we just did it." That was a poor answer and I knew it, so I have been pondering it every since.

Software Quality Assurance

Fri, 21 Oct 2005 22:50:29 -0500

The concept of quality has received a lot of coverage in the insight columns on this site, and I do not want to re-examine the timeless question of the origin of quality. Instead, I would like to concentrate on quality assurance. In the manufacturing industry, quality assurance is what drives the release of products and production benchmarks. The ability to produce X products with only Y defects is how production cycles are measured to ensure that they achieve the goal of maximum efficiency and profit. In manufacturing, the measurement of quality is determined by a set of tests which compare the recently created product to the accepted example or standard for the product. For creating software, the idea of quality assurance differs slightly because you are not replicating an already created product but instead creating a system based on already defined specifications.

My Stop-doing List

Thu, 13 Oct 2005 09:17:37 -0500

I have been back to work for almost two weeks now following a 2 week holiday. I usually take one long holiday a year because it offers me an opportunity to fully detach from my every day life and perform an intense audit of my day-to-day decisions. Normally, this time is completely devoted to my personal life, but this year I choose to concentrate entirely on my work life. This was mostly because I was having difficultly separating my work life from my personal life.

The Not So Quick Fix

Sat, 11 Jun 2005 12:31:03 -0500

We have all been at a place in the application life cycle where we encounter a problem in the application that creates an unexpected result. Sometimes there is a work around, other times the application must be patched. Patching an application should always be addressed carefully and approached with the utmost care. This opinion was recently strengthened in a recent (and ongoing) experience I am having with my lawn. Seriously, I'm not joking.

Independent Test Driven Development

Thu, 19 May 2005 23:52:35 -0500

There are quite a few development styles that exist in the area of software development. One of these is labeled "Extreme Programming". Besides having an edgy name, this style of development suggests many outside the box ideas for improving both the quality and speed of delivery for developing systems. Personally I'm a little skeptical of some of the methods, but one concept that does intrigue me is test driven development within a pair programming environment.

Decisions and Opinions

Sat, 14 May 2005 08:58:36 -0500

I love working at J & R. There are a lot of reasons why I feel that way, but one of the top reasons is due to the balance of opinions and decision making. This may seem like an odd balance pairing but it is vital to our company's success.

The Contingency Plan

Thu, 14 Apr 2005 21:39:04 -0500

In my opinion, one of the most overlooked line items in a Project Plan is related to contingency. Dictionary.com's definition of contingency is "An event that may occur but that is not likely or intended; a possibility." Or "A possibility that must be prepared for; a future emergency". Every good project manager allocates a certain amount of time and associates it as "contingency". However the actual plan for the contingency is usually left until the "future emergency" is the present emergency.

Maintaining Quality

Thu, 31 Mar 2005 10:07:11 -0500

Although rarely admitted quality is most often not the highest priority during application development. If it was then the project would have an un-restricted budget and the application "would be ready when it's ready".

Keeping your Eye on the Ball

Fri, 25 Mar 2005 07:37:14 -0500

In a large scale development project it is easy to become focused on meeting the Functional Requirements and lose sight of the purpose of these requirements. The Design cycle keeps in focus the ability for the end users to use the application after it is delivered.

Removing the "Personal" from Personal Experience

Sun, 13 Mar 2005 23:29:44 -0500

Creating a mechanism to share personal experiences will create an invaluable tool that will benefit each member of your current and future team.

The Danger of Scope Creep

Sat, 05 Mar 2005 11:34:57 -0500

The ability of a project to remain on time and within budget is linked to how well change in scope is managed and communicated between the design and validation teams.

Team Code Review

Thu, 24 Feb 2005 22:26:11 -0500

A structured presentation of each line of code is worth the time cost because each member of the development team benefits from each line of written code.

Team Design

Thu, 17 Feb 2005 22:24:26 -0500

Complicated user requirements require team input to produce a solid system design.

Proper Timing to Develop a Support Team

Thu, 10 Feb 2005 20:09:49 -0500

With every mission critical application there is usually a Support Model developed to keep the application running as smoothly as possible. The problem is that usually this Support Model is not formed until late in the development project, if not after deployment. In my experience the proper time to develop the Support Model and staff the team is during System Acceptance Testing.