Oxford Computer Consultants

Welcome to the third edition of the OCC eNewsletter with its insight into how emerging Information Technology will impact on your business.

Our aim is to inform business managers and technical directors in clear language about topical aspects of IT. Every quarter we'll explain how businesses are using IT to gain a competitive advantage and improve their business processes. Each article will be supported by case studies outlining how organizations have successfully deployed the technology, and how OCC has been able to help them seize the opportunities the articles outline.

In the next few issues we'll look at graphing and visualisation, the impact of semantics on web applications, database development options for 2006 and part two of our article on User Interface Design.

In this issue we take a look at certain approaches to software development and the best practices adopted by OCC.

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” (http://en.wikipedia.org/wiki/Agile_software_development) started to appear in the 1990s. The manifesto of the “Agile Alliance” (http://www.agilealliance.org/) 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:

• Add a test that fails → Write code to pass the test
• Remove duplication (refactor)

Test Driven Development, Damian Cugley, Consultant Developer

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 (http://www.cognisco.com/). 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 (http://eu.novagenus.com/novacast/weblaunch.aspx?I=CGSCOGENW)). 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.

Top

What is OCC?

The purpose of OCC (http://www.oxfordcc.co.uk/) is to create original, robust and flexible IT solutions. Our aim to add value to customers' businesses by enabling them to grasp the opportunities of information technology and the Internet. In so doing, we aim to give our staff challenging jobs and competitive rewards. We work in the IT field because we enjoy the technology, because we’re good at it and because we can see the positive impact IT has on both business and society. We aim to achieve our purpose by:

• recruiting and retaining highly skilled staff. We believe that the intelligence and skill of our developers is one of our competitive advantages,
• working closely with our customers. It is always our aim to allow any prospective client to contact any of our previous or ongoing clients for a reference,
• using our results and reputation to win repeat business and generate new business. We believe that our reputation should speak for itself; and
• undertaking leading edge R&D because this is the life blood of innovative companies. This ensures that we have expertise in emerging as well as current software technologies.

Find out more (http://www.oxfordcc.co.uk/Doc17747.html) about OCC's objectives

What Does OCC Do?

OCC promotes itself as having a strong ability to grasp a client’s business needs and to use technology to “add value” to client processes. Our strengths are reflected in the quality of our development staff, our high levels of repeat business (over 93% of clients buy again from OCC), and our knowledge and experience in specific sectors such as energy, engineering, local government and health.

OCC’s Services and Expertise

Software Services

A complete range of design, development and support services (http://www.oxfordcc.co.uk/Doc18139.html) for:

• Custom software applications;
• Re-engineering of software in legacy applications; and
• Content Management System based web sites and web applications based on standard and emerging web services technology.

Business Sectors

Over 16 years of experience, reference sites and testimonials from our customers in:

• Engineering and Energy Sectors (http://www.oxfordcc.co.uk/Doc18197.html);
• Public Sector (http://www.oxfordcc.co.uk/Doc18176.html) (including Local Government and the NHS);
• Blue chip companies such as Canon and National Grid; and
• Innovative SMEs in all sectors.

Technologies

All mainstream and emerging technologies (http://www.oxfordcc.co.uk/Doc18817.html) including:

• Database applications;
• Mathematical modeling software with graphical outputs; and
• Web applications based on Content Management technologies, web services and the semantic web.

Socially Responsible Business Practice

Oxford Computer Consultants adheres to socially responsible business practice (http://www.oxfordcc.co.uk/Doc17812.html). The company has formal environment and ethics policies that are communicated to all staff.