Introduction to FURST

The IAP has always engendered a professional approach to software development and members agree to be bound by its code of conduct. In an effort to sum up the concepts forwarded in books such as Clean Code and Code Complete, the acronym FURST has been created that will help in producing good software. This stands for Fit for purpose, Unit tested, Reviewed, Standard and Timely.

Fit for purpose (FFP) – does what it is supposed to do precisely.

Unit Tested – it can be relied upon.

Reviewed – check that it is well written compliant code that is easy to understand.

Standard – complies with all coding, UI, security and other applicable standards.

Timely – produced in time.

A Simple Analogy

Although producing a piece of software may not be the same as producing a more tangible product, for the purpose of a better understanding of FURST, the production of a car can be used as an analogy.

A car needs to be built within a certain time limit in order for the manufacturer to make money; otherwise there wouldn’t be any profit in the venture. The car is produced to certain requirements such as engine size, number of doors, top speed and utility such as the ability to fold down the back seats, to meet the customer’s needs. Besides being attractive, reliable and easy to drive, the car also needs to comply with government or agency standards so that it is safe to be driven on public roads. The manufacturer will employ a quality engineer to carry out or review a series of tests to ensure that the car meets both its own requirements and any standards laid down, such as health and safety and road worthiness. The quality engineer may use a ‘rolling road’ to test the car. The rolling road can be used for basic testing such as to ensure the brakes work efficiently and reliably and the exhaust emissions meet their own requirements and exceed the government standards. However, the rolling road cannot determine how the car handles in general, such as if it is a soft or hard ride, or how it handles corners. The rolling road is not part of the car and is never delivered to the customer, but without it there would be great difficulties in asserting that different sub systems or components within the car work to the prescribed limits.

A software product has to be built and delivered within a certain time for the venture to make money. The software will have a set of requirements that have to be met for the product to be useful to the customer (Fit For Purpose). These may include normal features, utility features and it will need to perform within certain limits. The software will also need to be reliable, easy to use and comply with certain standards such as security, safety, and look and feel amongst others. Unit tests are written to test the basic functions of the software to assert that it meets or exceeds the requirements and any compulsory standards. A reviewer will look at the product to ensure that the quality and other standards have been met and to check that the tests are valid and pass. However, the unit tests don’t test the behaviour of the whole system. The unit tests are not delivered to the customer, but without them it would be difficult to prove the basic functions work as expected.


The attitude of a non-professional programmer may be:

  • As long as the requirements are met, that is where the commitment ends – what is ‘fit for purpose’ anyway?
  • Why bother with unit tests, following standards and having someone else reviewing what I have done?
  • I may not be here when the software is delivered or needs upgrading, so it doesn’t bother me.
  • It will get completed when I finish, so why worry about time?

The whole purpose of software is to produce value for the customer. It must also be reliable and trustworthy, while for the company developing the software it must be easy to maintain and enhance.

Keeping code clean can help in optimising development, as the source code is always kept in a fit state, thus allowing flexibility for a change in priorities or requirements. Code is read many more times than it is written, so it must be easy to understand and change and it must look like all the other code i.e. standard and coherent. If it is changed, you have to be sure you haven’t broken anything and unit tests can help with this. Having other developers review all these points will ensure that these ideas are adhered to. All this must be done in a timely manner. Thus a professional attitude brings a lot more responsibility, but also produces rewards in creating a better quality product.


Using FURST you can check if there are Unit Tests in place, if the code has been Reviewed and if it has been completed within the current sprint (Timely). Standards are ones that an organisation demands to be followed, so the review can ascertain this. However, Fit for purpose may be more of a problem!

You can show that the code meets requirements and acceptance criteria and this would go a long way towards FFP. In an agile process this would be the minimum for any ‘Definition of Done’. However, the code could be a big ball of mud (because of legacy code) and at this point in time it works. Is this fit for purpose? It may not be reliable as a small change may take a long time to get working and its intent is not transparent i.e. it is not easy to read, understand or change and like beauty, it may not be pleasing. Therefore FFP, unlike the others is more subjective. You can say definitely if it is not FFP when the application doesn’t meet requirements or acceptance criteria, but the converse is not necessarily true.

What do you think?

The concept of FURST can be combined with the idea of professionalism to produce “Professionalism FURST”. The IAP would like your feedback on this concept. Is it useful, does it need amending, how can it be applied etc? Please let us know. You can email us here.