Software Development Practices

Software Development Practices

Many clients who visit OCC are interested to see how we undertake software development. This short article outlines the different approaches in the industry and where OCC stands on them.

A common approach, in use from the earliest days, is "Code-and-fix": you write the software, run it and fix the problems you find. It can work well on small projects but with complex systems it can be disastrous. A typical sign of such an approach going wrong is this: the software developer declares the project “complete” and delivers to the client. Problems arise almost immediately and are followed by a long test phase which plays havoc with the client’s schedules. When the software industry was born (a period now called the “Goldrush”), this unstructured approach led to painful lessons. Yet “Code-and-fix” will always be there, in the daily work and simple tests a software developer might run on their desktop. This simple approach needs to be held within a more reliable process.

In response to the problems of “Code-and-fix”, formal methodologies evolved, inspired by the classic branches of engineering. Classical methods try to plan the development process in detail several months or years ahead. The goal of the classical engineering method is to define a repeatable process that works well, whoever happens to be using it for whatever project. After a careful site survey and a design phase, it should be clear what steps need to be taken to build a new bridge over a motorway, and the order they should happen in. In software circles, these approaches are often referred to as “Waterfall” methods, the image being one of water pouring over a series of gentle steps, rather than bucketing over a cliff. Think of the Great Cascade at Chatsworth House rather than the Angel Falls. The steps are typically: analyse requirements, write specifications, design, code, test and deliver. (Spot “Code-and-fix”, still in there.)

The classical approaches struggled with the complexity and flexibility of software development. As projects get more individual, formal approaches should be used with care - (with Wembley stadium being a good example of a complex one-off project). A challenging aspect of software development is its exploratory nature. Even when the project stakeholders have a good grasp of the problem to be solved, it is not uncommon for improved solutions to emerge mid project.

In an attempt to get a balance between these two approaches, “Agile methods” started to appear in the 1990s. The manifesto of the “Agile Alliance” should be read as a response to classic software engineering approaches.

Agile Methods

Agile methods follow iterative development: aiming to frequently deliver working software to the client containing subsets of required features. So, when working on a stock inventory system, construction might take the following path: build a system that displays basic stock, then build an “Add item” feature, then build a “Retire item” feature, then add support for perishable items and so on. At each stage, working software is delivered, sometimes internally, and often to the client. This way the client knows where the development is and will see if the schedule is slipping. Should the client stop the project, they will still be left with working software.

This kind of adaptive process is challenging; it requires a close relationship between users and engineers and encourages an explorative approach. It is open to better solutions arising as the work progresses. The advantage is lower software risk - the client sees what they are getting often and early.

Agile methods have their limitations and their critics. They rely on good communication. You cannot use Agile methods well when developers and users are in different countries or time zones. Agile methods require a small, highly-skilled team rather than large teams of average engineers.

It’s no surprise that Agile methods were born from in-house development teams, where users and engineers can work closely together. The problems classical methodologies faced during the internal development of a payroll system for Chrysler gave rise to a series of innovations which resulted in Agile programming.

OCC’s Approach

OCC, like other software development contractors, cannot use a pure Agile method, but at OCC our best practice borrows from it. We are held within our client’s business constraints - we are hired to deliver business critical systems on time and on budget and have precious little space for an “exploratory approach”.

OCC’s method is best described as the Agile method called “Feature Driven Development” (inevitably, FDD). Feature Driven Development separates into two distinct project phases: the “pre-proposal” and “construction”. During the pre-proposal we work with the client to develop an overall model of what needs to be built; we develop a list of required features, which we then individually plan. This is a "one time" process and leads to the project proposal or contract. If the project is long and complex, developing the right model with the right features can become its own small consultancy project. The second “construction” phase is iterative and proceeds in a [Design by feature → Build by feature → Deliver] cycle, delivering incrementally the project with high client visibility.

We have adopted another practice which emerged from the same Agile movement, called “Test Driven Development” (TDD). Going back to the “Code-and-Fix” style of development, after a long hard period of finding and fixing bugs, a software developer could feel very unhappy, and worse still, their client would have probably walked away.

Test driven development is both more efficient and more satisfying for the developer, and ultimately, the client. When coding, the developer alternates these activities:

At a glance, this procedure appears to be backwards - write a test that fails and then write the code to pass it. It is, however, a better way to create software: writing a test is a quick way to discover if you understand the requirement. Failing the test at first is expected, and no disappointment. The testing drives the development and is not postponed to the final phases when client and developers think the software is ready.

Case in Point

At OCC our mature projects have large sets of automated tests that run overnight, every night. One client with whom we have worked closely with for a number of years is Cognisco. Cognisco are specialists in online assessment and training in large corporate environments. Their clients are large corporations, frequently multinationals. Hence their assessments, training and reports need to work 24/7 across cultures, time zones and in many languages, including Arabic and Hebrew.

Cognisco owns systems for authoring, translating, reviewing and deploying assessments, for gathering and interpreting the results and for directing and delivering the right training (Promotional video). Cognisco won the DTI Gold Smart Award and Exceptional R&D Grant Award in 2004. Developing software in this environment requires frequent communication and an iterative, collaborative approach to solutions. Over time we have developed large sets of automated tests, that take many hours to complete, running every night. The result has been a close and long relationship with a leader in their field.

Although all methodologies need to be adopted thoughtfully, with consideration given to each project’s needs, a client on an OCC project should expect close interaction with developers, they should be able to see regular demonstrations of software in progress and be prepared for emergent requirements which would be revealed early by this process.