One of the ways to escape the daily grind and focus on developing new skills is to participate in a coding dojo.

What is a Coding Dojo?

In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

-Dave Thomas

A coding dojo is a periodic meeting where developers practice the craft of coding together with the object of learning how to do it better. The discussion should center around design, testing, refactoring, and tools.

Safe Environment

Safety doesn't happen by accident

-Author Unknown

Creating a safe environment is not a given. The facilitator of a coding dojo is responsible for establishing the tone by delivering an intro explaining the objective of the meeting and reminding the team that it is okay to not know something and ask questions.

Each session should have a clear objective or focus and any code produced is purely for practice and should not be leveraged for real production software. It's this aspect of throw away code that allows coders to feel safe to experiment and possibly fail while obtaining a higher level of skill.

Should managers be there?

I don't recommend that managers attend this meeting, since it is a place for actual hands-on coders to code with each other. Having participants that are merely observing or making comments without being involved with the coding might ignite a spirit of fear which would be detrimental to the learning process.

If there are hands-on managers that want to learn and code along with the team, then the team can decide whether or not to allow it.

Retrospective/Reflection

Follow effective action with quiet reflection. From the quiet reflection will come even more effective action.

-Peter Drucker

Just as in any empirical process, it is important to step back and reflect on how well things are going at the end of the session. This will allow the team to inspect their progress and adapt. Make sure to give at least 10-15 minutes for this retrospective and come away with at most 1-2 action items for the next meeting. It is also important to recognize and document the principles that the team learns during the session.

Test-Driven

Feedback is the breakfast of champions.

-Ken Blanchard

Another essential component to any dojo is the practice of writing tests in addition to the code. These will provide feedback to participants to ensure that code works as expected.

Show working

The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.

-Aldous Huxley

Another important principle is to demonstrate how you write code - not just showing the final result of the code that you produce. The process or means is much more important than the product or the ends. This will ensure that the team learns the mechanisms for writing good code and not just what good code looks like.

This is very similar to the concept of learning by doing.

Which do you learn from more - reviewing someone's code in source control or pairing with that person to see how they produced it? How about listening to an instructor teach for hours or actually doing a lab under their supervision?

Frequency

If it hurts, do it more often.

-Jez Humble

How often should coding dojos meet?

There is no hard and fast rule to answer this question. But keep in mind that if you don't do it often enough (weekly or bi-weekly) you might not make much progress and members may become disillusioned with the process. And whatever interval the team chooses, make sure to keep it consistent so that people are willing to commit and look forward to the meetings .

Content

What should be the content of any given session?

We will discuss this topic in more detail in another post, but to begin with, consider working on a simple algorithmic problem in a tool of the team's choosing. So, for example, you might implement the Prime Factors algorithm using JavaScript. Or, you might want to implement the FizzBuzz algorithm using C#.

Chances are that if your development team doesn't, your operations group does. There are a variety of metrics that they are watching at a high level like CPU and memory usage performance counters and whether or not your applications and services are up or down. These help them to know whether or not there is trouble on the rise or if it has already arrived.

The alternative is to not monitor your applications and wait until something fails. The risk of the "wait-and-see" approach is much greater, however, because the stress and cost of fixing the issue may be high.

Monitoring in Other Domains

Application monitoring reminds me of the data-centric direction that healthcare is moving. In a podcast I heard recently with Peter Diamandis, he mentions that we will be seeing more and more bio-metric sensors that we can wear, ingest, or inject below our skin that constantly monitor what we eat and breath and our health levels such as glucose. Instead of waiting to deal with a problem that has become visible either to the naked eye or our sense of pain with critical care, we will be able to leverage preventative maintenance when conditions indicate that a problem is on the horizon.

This is very similar to the airline industry in which airplane engines are already equipped with hundreds of sensors that can indicate when anything is out of the norm, and when identified, immediately move the airplane into service mode for maintenance.

Most of our applications are not dealing with life and death consequences when they fail, but it is still vitally important to monitor our applications to sense when something is out of the norm so that we can prevent future issues.

Transaction Monitoring

Most monitoring is at a very high level and does not expose the kind of application details that a development group might be more interested at the transaction level. For each type of transaction, you may be interested in knowing the following metrics for a given time period:

• of Successful Transactions

• of Failed Transactions

• Average Execution Time for a Transaction

This kind of information would help development teams to know if their applications or any third party dependencies inside or outside of the organization are performing at expected or contractually agreed upon levels (service level agreements) for different types of transactions within the application.

Unfortunately, this kind of data is not automatically emitted from your applications as performance counters. It requires some custom code.

James.Diagnostics

I have released a new .NET library (James.Diagnostics) on NuGet.org that can make the set up and use of these counters relatively simple compared to the out-of-the-box method that Microsoft has provided. (If any of you have tried creating custom performance counters, you will know what I mean.)

James.Diagnostics is a convention-based library built on top of Magnum to help you to add custom performance counters to your existing applications. It is based on the assumption that in most cases you will want to instrument your application logic for:

• Successes

• Failures

• Average Execution Times

If you need other types of custom counters, libraries such as Magnum, written by Chris Patterson and Dru Sellers, can help you. If you are interested in reviewing the source code or contributing, you can find it here.

Installing the Library

From the package manager console in Visual Studio, you can enter the following:

> install-package James.Diagnostics

Creating Performance Counters

Let's say you have a service that allows clients to get and update customer information.

public IEnumerable GetCustomers()
{
    return _repository.GetAll();
}

public void UpdateCustomer(Customer customer)
{
    _repository.Update(customer);
}

Creating custom performance counters for these two methods is as simple as inheriting CounterCategory and implementing the IMonitorableCounterCategory for each as shown below.

public class CustomerService_GetCustomersCounters 
    : CounterCategory, IMonitorableCounterCategory
{
  public Counter Succeeded { get; set; }
  public Counter Failed { get; set; }
  public Counter ExecutionTime { get; set; }
}

public class CustomerService_UpdateCustomerCounters 
    : CounterCategory, IMonitorableCounterCategory
{
  public Counter Succeeded { get; set; }
  public Counter Failed { get; set; }
  public Counter ExecutionTime { get; set; }
}

Once you have these in place, you can begin to use those to Monitor() your methods.

public IEnumerable GetCustomers()
{
    return Monitoring<CustomerService_GetCustomerCounters>.Monitor(() => _repository.GetAll());
}

public void UpdateCustomer(Customer customer)
{
    Monitoring<CustomerService_UpdateCustomerCounters>.Monitor(() => _repository.Update(customer));
}

Below is a sample screenshot of Performance Monitor showing one of these performance counter categories in action. In the graph there are three colored lines representing the three counters.

• Blue Line - represents the execution times in milliseconds.

• Green Line - represents the number of successes.

• Red Line - represents the number of failures.

If these metrics are brought into tools such as SCOM, they can be further manipulated to derive computed metrics such as the percentage of successes or average execution times aggregated by time periods.

Synchronous Monitoring Options

There are multiple options for monitoring the execution of your synchronous code with custom performance counters.

void Monitor(Action action)

Takes an action and increments the success/failure counters depending on whether or not the action succeeds (ie. - does not throw). If an exception does occur, it will bubble this up.

T Monitor<T>(Func<T> function)

Takes a function and increments the success/failure counters depending on whether or not the action succeeds (ie. -does not throw). If an exception does occur, it will bubble this up. If it succeeds, it will also return the result of the function call.

void Monitor(Func<bool> function)

Takes a function that returns a true/false and increments the success/failure counters depending on whether or not the function returns a true or false. It will not return the boolean value to the client, however. So, only use this method if you are instrumenting something that gracefully handles exceptions by not bubbling them up.

Asynchronous Monitoring Options

Sometimes, the distance between beginning and ending your monitoring is not just in time but also by process or machine. This often occurs in distributed systems (especially messaging) where the process that you would like to instrument occurs on one machine or process and ends in another. James.Diagnostics has you covered in these scenarios.

Process 1: Sending Message

public void SendMessage(Customer customer)
{
    var message = new CustomerUpdate
        {  
            Customer = Customer, 
            Success = true,
            Start = DateTime.Now.ToUniversalTime()
        };

    _bus.Publish(message);
}

Process 2: Consuming Message

public void Consume(CustomerUpdate message)
{
    var elapsed = DateTime.Now.ToUniversalTime().Subtract(message.Start);
    message.Success 
        ? Monitoring<CustomerService_CustomerUpdatedCounters>.Success(elapsed)
        : Monitoring<CustomerService_CustomerUpdatedCounters>.Failure();
}

You will notice that in the case of the Failure() method, there is no TimeSpan to be provided. This is because a failure will either happen immediately or due to timeout, may be very lengthy. In either situation, you will not want to skew your average execution time metrics.

Conclusion

Whatever approach you choose to take, emitting transaction-level metrics are an important piece you should add to any of your applications to provide more insight. If you do try out James.Diagnostics, let me know. And any feedback you provide will be appreciated.

Hope it helps!

I drove up to a Chase ATM to transfer money from my Liquid account (re-loadable debit card we use for budgeting purposes) to our main checking account. (I know - it would be nice if I could just transfer this stuff online. Unfortunately, the Liquid account does not allow direct online transfers.)

First, I withdrew the $180 in the usual denomination of $20 bills. Then, I tried to deposit the same cash back into our main checking account. I waited for a few seconds while the machine chewed on my money and decided to spit out a $20 bill that it couldn't accept - something to do with the validity of the bill. Of course, I tried multiple times unsuccessfully, hoping each time to pass the validity check, but instead found that this darn machine wouldn't accept it's own cash!

So, I finally drove up to the bank parking lot and rushed into the lobby to find a line of 8 customers waiting to be served. Things are not looking good at this point for a quick transfer of cash. So, I go back outside and speed my car to the Chase business checking drive-through. I impatiently explain my quandary to the attendant.

"Your ATM machine doesn't seem to want to accept cash that I received as a withdrawal from another account. I don't know what the problem is. Can you help me?"

She curtly took my $20 bill and ATM card (presumably because I am not a business customer) and deposited the money directly for me. And when she came back to the microphone, she looked at me through the window and explained that while she was sorry for the mishap, the ATM machine belongs to another company and that they are looking to replace it soon. I said thanks and drove away a little confused.

Exactly what does that mean that the ATM machine is not theirs? It had their logo on it, and the software clearly displayed their brand name in its wizard to withdraw and deposit my cash.

How is that supposed to be a comfort to me as a frustrated consumer? All I care about is getting my money transferred quickly.

However, this incident got me thinking about how the same kind of thing can occur as we support our own software products and services.

It's easy for the internal and external teams that develop and support the software to blame each other to the customer for what caused a business critical incident. And there's plenty of reasons why.

Maybe a Windows Update patch to your servers caused your Windows service not to restart, leaving your customers high and dry. Or maybe one of the nodes in your web cluster went down and the health check that should have signaled your load balancer to redirect traffic to another node didn't work. Or maybe the third party service you use for some feature didn't live up to their service level agreements and were down during a critical time. Or maybe the Product Owner didn't understand what was best for their customer and had the team create a feature that just doesn't find acceptance with them.

Whatever the reason for the failure, from the customer's perspective the product doesn't work. And getting the problem resolved quickly should be the first order of business.

It's not one particular group that is ultimately responsible. Because when customers use our software, they only see one, unified product. They don't understand the intricacies of how and why a problem occurred. They only care that the problem occurred and that it needs to be fixed.

There will be time to get to the bottom of the root cause and figure out how to avoid it in the future, but for now, quality shows in how quickly you can respond and fix your customer's issues. So, anything that you can do to make that process smooth and easy is recommended.

So, think through what kinds of information your application should be emitting when trouble strikes and make sure that you have the proper tools, access, and support that you need to get to the bottom of an issue and enhance your application's maintainability.

And remember that quality is everyone's responsibility.

I waltz into the classroom looking forward to a new lesson and suddenly realize that today is the final exam. Everything I should have been preparing for is finally due. And I haven't done anything -- no flash cards, no notes, no readings, no late night, caffeine-infested sessions the night before. In fact, I can't remember if I have attended any of the prior classes.

As I begin to panic and look for an excuse to leave and make up the exam later, I wake up. It was all a dream - or a nightmare! It takes a few seconds, but I finally realize that nothing that I was experiencing is actually true. What a relief!

How About You?

But how many of us come to work unprepared each day?

I mean -- how well do we know our tools?

Do we know all of the ins and outs of our particular language, platform, tools, and techniques?

Or do we only know those parts that we had to use for our latest project?

Or do we only understand the basic "Hello, world" features that we learned from reading a blog, listening to a podcast, or attending a conference session?

Being a Passionate Programmer

This question came up in a book, The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) by Chad Fowler.

In it, he suggests that,

Our industry tends to practice on the job.

He then relates our craft to the art of playing music, and,

Musicians are paid to perform in public—not to practice.

So why would we expect to do it differently in our profession?

It takes hours of practice in order to learn our craft and, unfortunately, too many are practicing on the job these days, because it is acceptable. You cannot learn everything that you ought to know as a software craftsman by merely writing code for production software. Focusing on certain aspects is needed in order to increase the quality and resilience of what we produce.

One of the areas that musicians focus on developing is physical/coordination or focusing on fundamental technical aspects of playing an instrument. They do this by playing scales in all of the range of the instrument, building the muscles in their lips or gaining callouses in their fingers, practicing dynamics with their diaphragms, etc. They cannot always be playing nice sounding music - they have to play simple, focused, seemingly monotonous exercises to focus on these fundamentals.

How To Practice

How can a software craftsman do the same?

They can practice the full range of functionality available to them within a certain language, platform, tool, or technique, using them in private exercises known as code katas or building a demo project.

And even though they may not prove expertise in a particular technology, I have found certification exams to be invaluable in forcing me to look at the full scope of functionality that a platform provides.

For even more accountability and support, you could start/join a coding dojo, getting involved with a community of like-minded people wanting to grow in their knowledge and skills as well.

So spend some time thinking about what tools you already know something about and start practicing coding in areas of that tool or technique that you are not familiar with. Get to know what is available and practice the full range of motion. You will be much more prepared the next time you need to use that toolset.

Feel free to comment below on other suggestions you have for practicing our craft.

Is it something that you would mention when reviewing code for one of your team members?

Typically, when we review code we focus on making sure that:

1. It does what it is supposed to do

2. It handles potential failures

3. It avoids duplication

4. It performs well if it is computationally intensive

But when it comes to the readability of someone's code, we often don't want to mention it.

Why?

For some, it might be related to fear of being accused of being petty or nit-picky. Others might not want to stifle a fellow developer's personal expression or creativity. And others might be more focused on getting things done and feel that focusing on readability is a waste of valuable developer time.

Is Readability Important?

Today, I would like to suggest that readability is important. And, I will start by providing a couple of code samples to demonstrate my point.

Take a look at the following SQL statement and think about how long it takes you to figure out what it does.

SELECT * FROM dbo.MyTable WHERE ((PATINDEX('%[0-9]%', @Filter) = 0) AND (@Filter  LIKE '%,%'))

Now, take a look at the same code that has been made more readable.

SELECT    *
FROM    dbo.MyTable
WHERE    (
        (@filterContainsNumbers = 1) 
        AND 
        (@filterContainsComma = 1)
    )

By using the simple concepts of using reader-friendly layout and using intention revealing variable names, someone can quickly scan your code and understand it within a matter of seconds. The first example would probably take a few minutes to restructure the layout and look up the definition of the PATINDEX function.

Take a look at another code example written in C#.

public void RenderRemainingMoop(Liability source)
{
    var remainingMoop = source.OopRemaining + source.OopApplied;
    return remainingMoop == 9999999999 ? String.Empty : OopRemaining.ToString("{0:c}");
}

Now take a look at the more readable version.

public void RenderRemainingMaxOutOfPocket(Liability liability)
{
    const LiabilityMaxNumber = 9999999999;
    var remainingMaxOutOfPocket = liability.OutOfPocketRemaining + liability.OutOfPocketApplied;

    return remainingMaxOutOfPocket == LiabilityMaxNumber 
        ? String.Empty
        : OutOfPocketRemaining.ToString("{0:c}");
}

In addition to layout, using variables to provide context for magic numbers and strings and being descriptive instead of using abbreviations can better reveal what code is doing.

The Golden Rule

In both of the readable code samples, the developer focused not only on getting the job done, but also on making sure that future readers of their code would easily comprehend it.

And why is this important?

Because it makes the code more maintainable and flexible.

As mentioned in a previous post on software quality, maintainability is the effort required to locate and fix an error in an operational program. If your code is more readable, developers will be able to quickly understand it, which translates into quicker fixes. In that same article, it was also mentioned that flexibility is the effort required to modify an operational program. When developers need to add functionality to existing code, making it more readable will also allow them to quickly get up to speed and know where to place their functionality.

In both situations, you will be making someone else's job easier. As the golden rule states,

Do unto others what you would have them do unto you.

You never know when that someone else might be you!

Practicing the Golden Rule

So, what can we do to make our code more readable for others?

Using Intention Revealing Names

Everything in software has a name. And every time you name something, you have the opportunity to reveal its intention.

Be Descriptive

When naming things, be as descriptive as possible, and don't be afraid to use long names. Modern languages don't have many constraints when it comes to naming things, and the more descriptive, the better for the reader. There is no excuse for using abbreviations.

Provide Context for Magic Numbers and Strings

When using magic numbers or strings, make sure to assign them to a constant with a meaningful name. It helps to dispel the magic.

Be Ubiquitous

In Eric Evan's ground-breaking book, Domain-Driven Design: Tackling Complexity in the Heart of Software

, he establishes the concept of ubiquitous language, which establishes a common set of terms that can be used by both developers and business people alike. This helps to reduce the cognitive friction and potential confusion of having to translate between business concepts and code.

When you are naming something, prefer to use your domain's ubiquitous language rather than technical jargon. It will help reduce time and misunderstandings in the future.

Avoid Data Types in Names

In the past, using Hungarian notation to prepend an abbreviated data type to a variable name (examples: iCounter, bIsValid, txtFirstName, etc.) was in vogue, but it obscures the name by mixing the semantic meaning of a variable and its underlying data type. Modern development environments can easily reveal the type of a variable by hovering over the variable during debugging.

Using Reader-Friendly Layout

As shown earlier, laying out your code can make a big difference in how quickly a fellow developer (or even you, if you haven't seen the code for a while) can comprehend your code.

Show Logical Structure

Layout your code to emphasize the logical structure by using indentations and new lines. The examples below demonstrate this transformation.

--BEFORE
IF (@filter LIKE '%to%') BEGIN SELECT * FROM dbo.MyTable END
ELSE BEGIN SELECT * FROM dbo.MyOtherTable END

--AFTER
IF (@filter LIKE '%to%')
    BEGIN
        SELECT    *
        FROM    dbo.MyTable
    END
ELSE
    BEGIN
        SELECT    *
        FROM    dbo.MyOtherTable
    END

Avoid Run-on Sentences

Just as in good writing, you want to avoid the use of run-on sentences in your code. Instead of putting everything on one line as in the following example that uses a fluent syntax:

//BAD
var customers = eventsRepository.GetAll().Where(e => e.Date > DateTime.Now).Select(e => new Customer(e.FirstName, e.LastName));

you can do the following:

//BETTER
var customers = eventsRepository
    .GetAll()
    .Where(e => e.Date > DateTime.Now)
    .Select(e => new Customer(e.FirstName, e.LastName));

Or, instead of nesting multiple statements into one line for efficiency:

//BAD
var customer = GetOrderFor(GetCustomerFor(HttpContext.Current.User.Identity.Name), Convert.ToInt32(Session["orderId"]));

you might want to do the following:

//BETTER
var username = HttpContext.Current.User.Identity.Name;
var customer = GetCustomerFor(username);
var orderId = Convert.ToInt32(Session["orderId"]);
var order = GetOrderFor(customer, orderId);

While there may not always be universally accepted practices when it comes to layout, each team should decide on rules for code formatting and stick to them. Static code analysis tools can help to enforce those rules and modern editors include utilities for automatically formatting code according to your rules as it is being written.

Handling Conditionals

Another area where code can become unreadable is when using boolean logic in if and while statements.

Extracting Conditional Logic

For example, while the following code sample is fairly readable, it can be improved.

if (rolls[frameIndex] + rolls[frameIndex + 1] == 10) // spare
{
    score += 10 + rolls[frameIndex + 2];
} 
else 
{
    score += rolls[frameIndex] + rolls[frameIndex + 1];
}

Simply extract the logic contained in the boolean expression to another method, allowing the reader to understand the conditional logic from a conceptual point of view - in this case bowling a spare.

if (IsSpare(frameIndex))
{
    score += 10 + spareBonus(frameIndex);
} 
else 
{
    score += 10 + sumOfBallsInFrame(frameIndex);
}

Most modern development environments have built-in refactoring utilities that make this kind of operation trivial.

Negative Conditionals

Negative conditional logic can also obscure the meaning of an expression by creating cognitive dissonance that requires the reader to interpret. This wasted time could be alleviated by re-stating the condition in positive terms by creating a method to return the opposite of the intended expression.

For example,

if (!String.IsNullOrEmpty(value))
    doSomething();

could very easily have been written as the following.

if (ContainsText(value))
    doSomething();

For more information on making your code readable, check out Bob Martin's book, Clean Code: A Handbook of Agile Software Craftsmanship

System.NullReferenceException: Object reference not set to an instance of an object.

As you might have guessed, this is informing us that we are calling a method or property on an object that is currently null. The stack trace might be able to help us to locate where the error occurred. However, an ambiguous error like this can be hard to troubleshoot for multiple reasons.

• If the stack trace does not have line numbers and multiple local variables exist within the method, it can be hard to determine which variable was null.

public void Method()
{
    var person1 = new Person{ FirstName = "Todd", LastName = "Meinershagen" };
    var person2 = new Person();

    Console.WriteLine(person1.LastName);
    Console.WriteLine(person2.FirstName); //kapow!
}

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

• If the variable was an input parameter, it can be hard to determine which method within the call stack the null reference was introduced.

public void Method1()
{
    Person person = null;
    Method2(person);
}

public void Method2(Person person)
{
    Method3(person);
}

public void Method3(Person person)
{
    Console.WriteLine(person.FirstName); //kapow!
}

Failing Fast Enhances Maintainability

In my last post, I talked about the various factors that define software quality. One of those, maintainability, is very important, because it reduces the effort required to locate and fix an error in an operational program. Using a technique like failing fast can enable you and your team to locate errors more quickly in both development and production.

So, what does it mean to fail fast?

It means that rather than write code that ignores or band-aids an issue (like setting default values) and allows the code to limp along throughout the execution of your program, you fail "immediately and visibly" the minute that you are aware that there is an issue.

Assertions are the Key

In order to fail fast, the key is to use assertions in your code. An assertion is code that checks for a condition, and if the condition is not met, fails. In the case of the null object reference, you can do the following:

public void Method(int id)
{
    var person = _gateway.GetPerson(id);

    if (person == null)
    {
        throw new ArgumentNullException("person");
    }

    Console.WriteLine(person1.LastName);
    Console.WriteLine(person2.FirstName);
}

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

For null references, I like to check in places where two methods or classes interact:

• Constructor: verify any dependencies passed in by another class

• Method: check any input parameters passed in by another method or class

• Method: check the response from another method or class, as in the case with the Gateway call above

Drying Up Your Assertions

After using these kind of assertions throughout your code, you would want to DRY (don't repeat yourself) your code and create reusable assertions. Below is one example.

public class Assert
{
    public static void IsNotNull(object value, string paramName)
    {
        if (value == null)
        {
            throw new ArgumentNullException(paramName);
        }
    }
}

You might also look into third party libraries such as Magnum by Chris Patterson that are available as NuGet packages. Below is an example using the Guard class that Magnum provides for these kind of common assertions.

public void Method(int id)
{
    var person = _gateway.GetPerson(id);

    Guard.AgainstNull(person, "person");

    Console.WriteLine(person1.LastName);
    Console.WriteLine(person2.FirstName); //kapow!
}

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Another option, if you are using the .NET framework, is Microsoft's Code Contracts. These allow the developer to specify pre- and post-conditions that can also be seen in the documentation of a given method. A discussion of their use is outside the scope of this article.

Is Failing Fast Robust?

At this point, some may object and say this technique of failing fast will create fragile software. However, by failing fast, errors will more likely be found during development and testing of your software, rather than in production where it really counts. And if a bug does escape in production, your team will more likely be able to fix the issue quickly by failing closer to where the issue originally occurred.

Another objection to this style of programming is that it will more likely cause the system to crash in front of the user. One way to mitigate this is to use a global error handler that gracefully displays a user-friendly, generic error message to the user while providing the error details to developers through logs or email. In the case of non-interactive applications such as batch processes or windows services, you don't have to display a message, but after handling the error globally, operations continue by moving on to the next action/transaction.

Other Resources

If you are interested in reading more about the concept of failing fast, check out James Shore's article for IEEE magazine discussing the same topic.

Would you have answered, "a really nice/slick/sexy user interface?" Or perhaps you would have said, "absence of known defects or bugs." Those in the TDD camp might have replied, "thoroughly tested and validated with automation." Or an architect might have preached about the importance of one or more of the -ilities.

A History of Quality

Turns out that same question was asked of Jim McCall and his answer was captured in a study he conducted for the Air Force in 1977. What's surprising is that its findings are very similar to what we still claim as quality for applications today.

In his study on the subject, he initially identified 55 factors of quality. In order to make the study more practical he reduced those 55 quality factors down to 11 and grouped them into 3 categories:

• Product operation - how well it runs
• Product revision - how well it can be changed, tested, and deployed
• Product transition - how well it can be moved to other platforms and interface with other systems

The diagram below shows a visual representation of his findings.

Definitions of Quality Factors

Below are definitions of each of the quality factors.

• Correctness - Extent to which a program satisfies its specifications and fulfills the user's mission objectives.
• Reliability - Extent to which a program can be expected to perform its intended function with required precision.
• Usability - Effort required to learn, operate, prepare input, and interpret output of a program.
• Integrity - Extent to which access to software or data by unauthorized persons can be controlled.
• Efficiency - The amount of computing resources and code required by a program to perform a function.
• Maintainability - Effort required to locate and fix an error in an operational program.
• Flexibility - Effort required to modify an operational program.
• Testability - Effort required to test a program to insure it performs its intended function.
• Portability - Effort required to transfer a program from one hardware configuration and/or software system environment to another.
• Reusability - Extent to which a program can be used in other applications - related to the packaging and scope of the functions that programs perform.
• Interoperability - Effort required to couple one system with another.

Today's View on Quality

This list should help you to think at a high level about the necessary factors involved with creating high quality software. In more recent years, the literature on quality group the factors under either internal or external quality which are more concerned with the stakeholder rather than the product.

• External Quality - concerned with the end user's experience in using the product; these include all of the Product Operation factors
• Internal Quality - concerned with the developer's experience in maintaining the product; these include all of the factors listed in the Product Revision and Product Transition categories.

While the external quality is of utmost importance in delighting customers, if internal quality factors are ignored, over time, delivering new external quality will be hampered.

You may be asking yourself,

Why is Todd starting a new blog?

The short answer is that it helps me to clarify my own thinking. Below is a quote I read in a book by Dr. Howard Hendricks that I think describes the process pretty well.

“Thoughts untangle themselves over the lips and through the fingertips.”

Isn't it funny how the simple act of talking about an idea or writing it down helps to untangle and clarify it?

My other aim is to share my opinions and ideas with you. I hope that this will be a small contribution to the community from which I have learned so much. As Bernard of Clairvaux once said,

There are those who seek knowledge for the sake of knowledge; that is Curiosity. There are those who seek knowledge to be known by others; that is Vanity. There are those who seek knowledge in order to serve; that is Love.