Does Rapid Application Development reduce the quality of Information Systems?

Does RAD reduce the quality of

Christian Wimmer

School of Computing and Communications Technology, North East Wales Institute, United Kingdom

1. Introduction

Few words have been more used and misused today then quality (Jansen and Ølnes 2004). Two definitions of the quality of an Informaton System (IS) are (Dahlbom and Mathiassen, 1993, Braa and Øgrim, 1995):

• a system’s capability to satisfy needs, expectations and requests

• the proportion between expected and experienced yield of a system

It is the aim of this paper to see if RAD can meet these quality definitions and if RAD can be used to produce high quality IS – or if it is really only ‘quick and dirty’ as some claim.

2. RAD: one word, many meanings

Originally the acronym RAD stands for Rapid Application Development. The term appears to have first been used by James Martin in 1991 (Avison & Fitzgerald, 2003 p 94). Nowadays RAD is used to describe a variety of things.

James Martin’s RAD (JMRAD): This is the original RAD methodology developed by James Martin (Martin, 1991). This methodology is not based on the traditional life cycle but uses an evolutionary approach.

page 2 of 8

Dynamic Systems Development Method (DSDM): This methodology is non- proprietary RAD-like approach created by the DSM consortium, a union of vendors and users and individual associates of RAD (Beynon-Davies et al, 1999). DSDM is being developed in the UK and provides a framework for RADish software projects. In a way DSDM can be seen as a “grown-up” JMRAD.

Marketing RAD: The term Rapid Application Development is often used in marketing literature such as brochures to praise the effectiveness of the software tool in question. Typical marketing phrases are used, promising development speed increases of “up to 50%” (Richardson, 2005) however this tools rarely implement all aspects for RAD and therefore the term RAD is often misused.

Therefore RAD can be categorized as two ways: A methodology, whether it is classic

JMRAD or the more modern DSDM, and a class of tools that allow ‘speedy’

application development (Agarwal et al, 2000).

3. RAD and quality

RAD – Rapid application development. That is, developing software faster than

normally. This alone can be seen as quality criteria. The IS is what the organisation needs right now – and not in 2 years when the whole environment changed. A, maybe unperfected, system that is exactly what is needed in 6 months can be seen as having a certain level of quality – a perfect system in 3 years that fails to meet the business needs is useless and will be seen as having low quality.

CASE tools are often used within RAD projects. This kind of tools enables one to

create relatively good code in a fraction of the time it normally takes (Butler, 2000). They make reuse of code easier and because the existing code has usually been tested in real use it has a certain level of quality (Avison & Fitzgerald, 2003).

RAD relies heavily on user involvement whether it is in the initial JAD/JRP

workshops or in the ongoing prototyping. This ongoing process builds user commitment and allows the system to be “closer to the user” (Jones and King, 1998). One of the principles of DSDM is ‘fitness for purpose’. This term describes the user acceptance of the IS deliverable, and this is what, from a users point of view, is what

page 3 of 8

quality is. In other words, quality will be built into the IS when DSDM is used as the methodology of choice.

James Martin (1991) believes that RAD will lead to higher quality systems developed faster and therefore cheaper than systems that use the traditional lice cycle approach. A decade later Howard (2002) however suggests that: “For some RAD, will always stand for “Rough and dirty” development – an excuse for sidetracking the discipline of software engineering standards”. Yourdon (2000) feels that in nowadays projects the temptation to skip these standards is even greater, particularly while developing e-business IS.

Daniels(1996) argues that RAD ignores the long term and only focuses

on the business functionality at that time. Reilly and Carmel (1995) found that “most RAD projects skip design and rigorous methodology altogether”. Palermo (2006) also thinks this is cause for concern and compares RAD with tobacco products: Soothing in short-term, addictive and deadly in the long term, while causing irreparable damage along the way. McConnelll (1996 p366) goes as far as saying that “RAD has become more of a rallying cry for faster development than a meaningful methodology”.

But is RAD really “anti-quality” (Howard, 2002) or can it be used to produce quality systems in reality? A look at the available case RAD case studies might shine some light on this situation.

4. RAD projects: A Classification

Beyon-Davies et al (2000) identified two different types of RAD projects which they call highly intensive or phased respectively. In simple terms in highly intensive projects developers and users are “locked away” in a room for some weeks and are expected to produce a working deliverable at the end of the time. On this type of projects the emphasis clearly lies at the rapid part of IS development.

A phased project on the other hand is one that is spread over several of months (or

even years). This kind of projects is a much more classic example of projects

page 4 of 8

following a methodology with phases, however RAD techniques such as JAD workshops, timeboxing and prototyping are used along with CASE tools to speed up the development.

A different approach to classify RAD type projects is to differentiate what the

deliverable will be (Howard, 2002). Rapid Program Development (RPD) focuses on implementing a given program based on a program specification as fast as possible. Experienced Programmers are required to code nearly bug-free code under strict time constrains. Communication with the users is hardly ever required, if at all and therefore the interpersonal skills of the RPD staff doesn’t need to be as highly evolved. The typical picture of a coder locked in a dark room who produces lines and lines of code is one that can come to ones mind when looking at this kind of rapid development.

Rapid System Development (RSD) is a much more chaotic process than RPD. Projects start with a set of ideas for a new or updated Information System (IS). This ideas need to be refined to a system specifications with all the details necessary. Extensive user involvement is required therefore developers need technical as much as interpersonal skills. This kind of development relies heavily on a good development team that can adapt the initial system specification and create a working system that ‘adds value to the business operation’. Howard (2002) classifies

RAD as value engineering, reasoning that value is the operative word in RSD.

Case Study: BT Face

This project was conducted within the company BT and is the second iteration of a Intranet for intra-organizational communication (Beynon-Davies et al, 2000). The case study is especially useful as it follows the main RAD principles.

In the project a small team of users and developers where working in a remote location, far way from their normal working place and they where expected to deliver a working IS after 3 weeks – a typical intensive project. Their working environment was what the literature calls a ‘clean room’ – places free from everyday work equipped with supporting equipment such as flip-charts, coffee, computers and such. One member of the team described their project as “It's a Lot of Bits of Paper and

page 5 of 8

Ticks and Post-It Notes and Things” which sounds pretty chaotic therefore this project can be classified as being Rapid System Development (RSD).

The case study doesn’t clearly state if the project produced a quality IS, however it is noted that the team didn’t work overtime and that the project presentation at the end of the project went well so it can be concluded that the system met the users and management expectations. It is also interesting that the people involved in the project said that it was the purest they ever took part in.

5. Conclusion

The material available on the quality of RAD projects is inconclusive. On the one hand there is evidence that RAD is being successfully used with small to middle size projects on the other hand there is a lot of material that claim RAD projects are ‘quick and dirty’. In the end it probably depends on the quality of the people involved in the project and how well RAD is being used. Looking at the case studies and the often mentioned maximum size of a RAD team it can be said RAD is suitable for small to middle size projects and the quality of the deliverable can be quite good. However, except for one inconclusive case study (Berger et al, 2004), there is little evidence that RAD can be used in big projects. Maybe project managers are just too afraid of using a “new” methodology that is said to produce ‘anti-quality’ systems for mission critical projects. If an organization isn’t ready for RAD it shouldn’t be forced upon it as the cultural changes that go along with it are quite extensive. In the end it probably comes down to what you expect from a systems and how far this expectations are met. If project managers choose RAD only because it promises faster IS development and forget about all the good practices of normal methodologies the quality of the IS is sure to suffer.

RAD isn’t one size fits all and it clearly isn’t the solution of the quality problem,

however if it used like its meant to be and the people involved in the process now what they are doing it can be used to produce quality Information Systems.

‘It's a Lot of Bits of Paper and Ticks and Post-It Notes and things… you’ll get to understand it, it’s not that bad really’ (Beynon-Davies et al, 2000)

page 6 of 8

6. References

Agarwal Ritu, Prasad Jayesh, Tanniru Mohan and John Lynch (2002) ‘Risks of Rapid Application Development’. Communications of the ACM, vol. 43, Issue 11, p177

Avison, D. & Fitzgerald, G. (2003) Information systems development: methodologies, techniques and tools (3rd edn) London: McGraw-Hill

Berger, H., Beynon-Davies, P. and Cleary, P. (2004) The utility of a rapid application development(RAD) approach for a large complex information Systems development [paper presented at the 13th European Conference on Information Systems, ECIS 2004, Turku, Finland, June 14-16, 2004] University of Wales

Beynon-Davies, P., C. Carne, et al. (1999) ‘Rapid Application Development: an empirical review’ European Journal of Information Systems. 8(2), 211-223.

Beynon-Davies, P., McKay, H. and Tudhope H. (2000) ‘It's a Lot of Bits of Paper and Ticks and Post-It Notes and Things: A Case Study of a rapid application development project’ Info Systems J(2000) 10, 195-216

Braa, K. and L. Øgrim (1995): “Critical View of the Application of the ISO Standard for Quality Assurance”, Avison & Fitzgerald (1995) Information Systems Journal

Butler, T. (2000) ‘Transforming information systems development through computer- aided systems engineering (CASE): lessons from practice’ Information Systems Journal 2000, Volume 10, 167-194

Casemaker Inc. (2000) What is Rapid Application Development? [corporate whitepaper] http://www.casemaker.com/download/products/totem/rad_wp.pdf [Electronically accessed 30th March 2006.]

Dahlbom, B. and L. Mathiassen (1993): Computers in Context, Basil Blackwell

Daniels, J. (1996) Why RAD is Bad! Presentation to the British Computer Society Requirements Engineering Specialist Group, July 10 th 1996, Imperial College, London. Cited by Jones and King(1998)

Howard, A. (2002) ’Rapid Application Development: Rough and Dirty or Money Engineering?’. Communications of the ACM, vol. 45, no. 10, p27

Jansen, A. and Ølnes, S. (2004) Quality Assessment and Benchmarking of Norwegian Public Web Sites [paper to be presented at 4th European Conference on EGovernment, Dublin, 17-18.6.2004] Western Norway Research Institute Sogndal, Norway

Jeffrey Palermo (2006) RAD kills. . . software - level 200

http://codebetter.com/blogs/jeffrey.palermo/archive/2006/02/20/138778.aspx [Electronically accessed 31th March 2006.]

page 7 of 8

Jones, T. and King, SF. (1998) ‘Flexible systems for changing organizations: implementing RAD’ European Journal of Information Systems (1998) 7, pp 61–73

Martin, J. (1991) Rapid Application Development, Prentice Hill, Eaglewood Cliffs, New Jersey.

McConnell, S. (1996) Rapid Developmenmt – Taming Wild Software Schedules, Microsoft Press, Redmond, Washington

Reilly, J.P. and Carmel, E. ‘Does RAD live up to the hype?’ IEEE Software (Sept. 1995), vol. 12, no. 5, pp. 24-26

Richardson, Lee (2005) Cracking the Code [online article] http://www.gantthead.com/article.cfm?ID=227410 [Electronically accessed 30th March 2006.]

Yourdon, E. (2000) Computerworld, 21. August, Vol. 34, Issue 34, 36. Cited by Avison & Fitzgerald (2003) p99

page 8 of 8