Home > Resources > Quality of Code

Quality of Code

Why read this article?

Perhaps you work with programmers or you're commissioning a new project. Understanding that software can have limitations like real world objects, you can better appreciate the concerns of programmers and make informed decisions.

This article contains small snippets of programming code accessible by clicking the 'Show Code' button. You do not need to read or understand this code. It serves to show the scenarios described can and do relate to real programming situations.

Developers and users alike frequently decry the quality of software. Though claims of quality are universal and no vendor admits to producing bad software, the standard of software and the programming code that makes that software is generally regarded as poor.

In developing software, programmers introduce constraints that affect performance and maintainability. There are many ways of acheiving the same outcome in software development, unfortunately the quickest path to producing software is the most likely to introduce unreasonable limitations that are not immediately apparent.

The internals of software are opaque and it is difficult, especially for those not familiar with programming, to assess the standard of programming. When faced with two superficially identical options the natural choice is the cheapest option.

There are essentially two ways of looking at the quality of an application, how it behaves and how easy it is for developers to maintain and improve. The former I have characterized as Quality of Performance, which naturally receives the most attention from end users; the latter as Quality of Code, which is often neglected. This article will attempt to provide some insight into the consequences of Quality of Code and how it ultimately impacts on the Quality of Performance and the cost of development and maintenance.

Quality of Performance

There are an innumerable number of profiling methodologies that purport to quantify quality. Most commonly, software quality is measured in terms of application performance with respect to expectations.

Fulfilment of explicit expectations

The easiest method of measuring quality is the comparison of application functionality against explicitly predetermined requirements. An application that does not fulfil the stated requirements must be regarded as being of poor quality. The measurement of explicit requirements is typically where most quality analysis ends.

Fulfilment of implicit expectations

We necessarily define requirements at different levels of abstraction, often making assumptions about lower level implementation details. For example, there may be a requirement for a message to appear when a user activates a given button. The assumption is that the message will appear quickly enough to be associated with the action.

It is important to appreciate that even if an application supports all the explicit requirements, it must also fulfil implicit requirements to be regarded as high quality with respect to performance.

Quality of Code

The relative quality of code is a matter of subjective opinion, however for most experienced programmers it is likely to be a combination of consistency and adherence to coding standards, fault tolerant design and the adaptability of code to new requirements.

Coding standards and quality

How do coding standards impact on application quality? Coding standards matter because they affect the maintainability and adaptability of an application. It is far easier for a developer to identify and repair faults in an application having consistent standards than one without.

Code written to a standard

decimal productPriceL = 123.45M;
int productQuantityL = 8;
decimal taxRateL = 0.1M;

decimal totalPriceL = productPriceL * productQuantityL * taxRateL;

Code written with no adherence to a standard

decimal x = 123.45M;
int y = 8;

decimal z = x * y * 0.1M;

The above examples provide equivalent functionality, but even for a novice the code written to a standard is much more comprehensible than that not written to a standard.

Defensive programming

Good standards also define defensive coding practices that lead to more robust, fault resistant applications.

Each line of programming code in an application is like a worker on an assembly line. In the same way as each worker on an assembly line adds to a product until it is complete, each line of code performs some function within the software, creating a desired outcome.

An operating assembly line where everything is working correctly.

Poorly designed, or optimistically written software, assumes everything will work properly all the time. When errors inevitably occur the results can be disasterous.

An assembly line where something has gone awry but the line keeps operating, compounding problems and wasting resources.

assemblyLine.Start();

assemblyLine.Process(orders); // <- If something goes wrong here ...

assemblyLine.Stop(); // <- ... this line is never reached, and the application can become unstable.

Well designed code expects problems and is designed to cope when the occur, minimizes the potential impact of failure.

An assembly line where a fault has been detected and the line halted.

try
{
	assemblyLine.Start();

	assemblyLine.Process(orders); // <- If something goes wrong here ...
}
finally
{
	assemblyLine.Stop(); <- ... this line is always reached, preventing further problems.
}

Adaptability

Adaptability is important, because it reflects the cost of upgrading or modifying the code to fit with changing requirements. Good code seperates aspects of the software into components that can be efficiently adapted, in the same way the tools of a car factory can be adapted or re-used in producing new model vehicles. It would not make sense to build an entire car factory that could only ever manufacture a single model of car. If a new model was required the entire factory would need to be rebuilt.

In order to help appreciate the quality of adaptability consider the following scenario. We have a virtual car factory that needs to manufacture cars at the push of a button. Given this requirement a programmer might develop a solution like that in the example below.

First Car Factory

A control panel with the vehicle types built into the switch. Adding a new vehicle means building a new switch.

public class FirstFactory
{
	public void BuildVehicle(string vehicleType)
	{
		switch(vehicleType)
		{
			case "sedan":
				//... code to build sedan

				break;

			case "coupe":
				//... code to build coupe

				break;
				
			case "hatchback":
				//... code to build hatchback

				break;

			/*
			Adding support for a new vehicle means editing and potentially
			breaking existing code.
			*/
			case "wagon":
				//... code to build wagon
				
				break;

		}
	}
}

This is a solution that fulfills immediate requirements and is typically quick and easy to create. However, it is a limited solution because it means dismantling and rebuilding factory controls and potentially disrupting operations, if support for a new model is required.

Second Car Factory

With a little more thought and effort a better solution would take into account the potential for future changes.

A control panel with the vehicle types listed in an expandable display.

public class SecondFactory
{
	public void BuildVehicle(string vehicleType)
	{
		IVehicleBuilder vehicleBuilder = GetVehicleBuilder(vehicleType);

		vehicleBuilder.BuildVehicle();
	}

	public IVehicleBuilder GetVehicleBuilder(string vehicleType)
	{
		XmlDocument builderReferences = new XmlDocument();

		builderReferences.Load("builders.xml");

		XmlNode builderDescription = builderReferences.SelectSingleNode("/builders/builder/type=" + vehicleType);

		Type builderType = Type.GetType(builderDescription.InnerText);

		IVehicleBuilder vehicleBuilder = (IVehicleBuilder)builderType.GetConstructor(Type.EmptyTypes).Invoke(null);

		return vehicleBuilder;
	}
}

public interface IVehicleBuilder
{
	void BuildVehicle();
}

public class SedanBuilder:IVehicleBuilder
{
	public void BuildVehicle()
	{
		//... code to build sedan
	}
}

public class CoupeBuilder:IVehicleBuilder
{
	public void BuildVehicle()
	{
		//... code to build coupe
	}
}

public class HatchbackBuilder:IVehicleBuilder
{
	public void BuildVehicle()
	{
		//... code to build hatchback
	}
}

/* 
Support for a new model can be added without touching old code or 
even modifying the existing application.
*/
public class WagonBuilder:IVehicleBuilder
{
	public void BuildVehicle()
	{
		//... code to build wagon
	}
}

Although it may require more upfront effort, the second example provides superior adaptability, reliability, easier maintainance and ultimately greater speed of development. With this approach new models can be added seamlessly without intefering with existing components or disrupting the factory.

Conclusion

The more we strive to introduce flexibility, the more there is involved in the initial development of the solution. Conversely, the greater the initial investment, the lower the maintenance effort, long term costs and obstacles to future enhancement.

It is much more difficult to appreciate the complexity and limitations in the design of software than concrete real world objects. While an application such as a word processor is much more complex than a car, we can better understand the limitations in the cars design. The intangible nature of software often leads us to underestimate the constraints dependent upon implementation. Although it is theoretically possible, we don’t realistically imagine we can turn a mid range Toyota sedan into a Formula One racing car, but there is a pervasive belief that a small undemanding website can be transformed into the next eBay.

Any feedback or questions regarding this article are welcome. You can contact Alden Systems through the contact form