Theories of Rationality Applied to Information Systems Development - Assignment Example

Theories of Rationality Applied to Information Systems Development Table of Contents Topic Page # 1. Introduction ------ 3 2. Objective ------ 4 3. Scope ------ 4 4. Method of Research ------ 4 5. Data Section ------ 5 5.1. The Concept of Rationality ------ 5-7 5.2. Relationship of Rationality and Information Systems Development Methodologies ------ 8-9 5.3. Effectiveness and Limitations of New Information Systems Development Approach ------ 9-11 5.3.1. The Agile Development Methodology ------ 11-12 5.3.1.1. How agile is Agile Development ------ 13-14 5.3.2. Extreme Programming ------ 14-16 5.3.2.1. How extreme is Extreme Programming ------ 16-19 5.3.3. Assessment of Effectiveness and Limitations ------ 19-22 6. Conclusion ------ 23-24 7. Bibliography ------ 25-26 1. Introduction The theory of rationality has been around for decades and it is the centre of studies of most philosophers, psychologist, and even information systems development professionals. The main objective is to come up with set of rules and principles that could set a standard for humans to reason precisely or rationally. The focus is not on the outcome of rational acts but on making rational choices in a number of assumptions. The study and incorporation of the theory went beyond the boundaries of experimental psychology to the doorstep of information systems development methodologies where decision-makers insight and analysis is significant. Software development is a social atmosphere where everyone can speak out, articulate his feelings, and treat system analysis and design as communication and a learning process. Rationality is therefore crucial to diagnose distorting communication tendencies within the software development process where actions are only acceptable on rational grounds and adhering to the appropriate organizational rituals. Modern software development methodologies and techniques such as Agile and Extreme Programming are products of long experience and are probably on rationality-oriented. The following pages contain these topics and some discussions on other relevant concepts. 2. Objective The aim of this paper is to gain sufficient knowledge of “rationality” applied to Information Systems Development, as we believe that being rational will help developer produce much better software in the future. For accuracy and better understanding, this paper will try to establish the link between rationality and ISD and draw some relevant conclusions in the end. Another objective is to research and identify the concept of newer or modern systems development methodology that we think is relevant to the main topic of this paper and to the future of ISD. 3. Scope The paper will going to present some significant insight on rationality, its relevance to ISD and its specific application to the elements of software development. Furthermore, it will put forward detailed discussion about Agile Development and Extreme Programming. It will discuss its effectiveness and limitations, and how it is different from traditional software development methodologies. This paper will conclude by summarizing what we learn and present our own understanding and opinion of the topic discussed. 4. Method of Research The details and information on this paper will depend largely on literature review using reliable scholarly books, journals, and web content. 5. Data Section 5.1. The Concept of Rationality Rationality's common interpretation is man’s ability to construct a valid logical argument or reasoning- “a rational thing for each of us to do is what will be best for himself” (Parfit 1982, p.227). On the other hand, some other author also argues that rationality necessitates a person not to have opposing intentions or beliefs and not to plan to do something he supposes is not doable (Broome 2004, p.2). According to Samuels et. al. (2004), reasoning and rationality have been around for decades and catching the fancy of philosophers, psychologist, economists, and other scholars. Their interest laid bare some study of the topic reflecting the nature of reasoning in human affairs to gain comprehensive understanding of how people essentially go about the business of reasoning and its underlying mechanisms and processes. Furthermore, some research went deeper to discover not only how people actually reason but with how they should reason. These studies predominant objective is to learn the rules or principles that could clearly specify how to reason correctly or rationally and identify standards that can be use to measure the quality of human rationality (1). To be more precise, the science of psychology regard rationality as a preference made by a person based on reasoning and not by spontaneous choices and deeds arising from gut feelings. Psychologist recognized it as a procedure of selecting an act and not by the outcome generated by that act. Rational choices frequently depend on the number of postulation. For instance, if a person were to decide on two actions say X and Y where he could obtain £20 from action X and £10 from action Y, choosing X would be rational as people would naturally prefer more money. In reality, resolutions of some ambiguity are indiscriminately settle by natural occurrence but in most cases these ambiguities are ought to be solving by actions or decisions. Therefore, knowing the difference is imperative, as the nature of uncertainty involved will greatly affect the decision maker’s insight and analysis of the situation (Muthoo 1998, p.1). Contrary to the efficacy of rational choices, Davidson (2004) argues that the problem with rationalizing things is the uncertainty of our beliefs. How can we tell that our belief is true? and what makes belief true of false?. According to him, our thought, whether in the form of belief or intentions, desires, fears, and expectations has propositional content that articulated normally by sentences (3). Consequently, we cannot have truth without understanding whether a thought’s propositional content maybe true or not as characteristics of propositions are by their truth conditions. This statement came from the reality that our intentions may or may not come about or our desire and expectations may not be achieved (4). Making a judgement entails interpersonal evaluation of interest and the common intuition of our moral principles and standards applied analogously to such judgement as to personal decisions, and it is outlandish that we find it complicated to describe our personal judgement. The problem is not the absence of psychological explanation but the absence of satisfactory view of the basis for our interpersonal comparisons (59). Furthermore, basing on the simplest logical matters, partaking of standards of rationality is an unavoidable artefact of interpretation. This is based on the reality that no one is a “perfect logician” (50) and we anticipate failures in reasoning where our memory plays an imperative function and sentences become complex in an environment bursting with distractions and temptations. In these situations, interpretations are complex and can easily put anyone into selecting amid similarly logical facts and make erroneous decisions (50). Another opposing view presented by Biderman and Scharfstein (1989) is the misconception that compliance to logic is an essential stipulation of rationality (3). Every human being want to have much truth and little error and success to this undertaking bank on the facts of the aspect of world to which we are acting in response, as this will give us the truth that we all want to have. However, there are situations when it is practical to believe what subsequently turns out to be false. “Justification involves knowledge and errors” (4). Unfortunately, rationality is even powerless and more general than justification since we have to engage in the enterprise of trying to find truth and shun away from errors. Undoubtedly, we call ourselves rational if we are trying to validate and appraise our own beliefs to augment the probability of achieving the truth and diminish our errors. However, rationality does not guarantee that we could achieve these goals, as it is merely pointing out the resolution and telling us to pursue them in a particular way (4). Apparently, the core concept of rationality is the capability of a person to make the right decision thus rationality of actors in an organizational processes is crucial to the success or achievement of their predefined goals. To ensure that such human reasoning flaws mentioned by Davidson (2004) and Biderman and Scharfstein (1989) will not affect rationality of actors particularly in information system development, developers are aided with machine-oriented tools, and methodologies described in the next topic. 5.2. Relationship of Rationality and Information Systems Development Methodologies “Rationality is an implicit goal of most information systems developments” (Cukier et. al. 2004, p.237). There are few variations of factors influencing and shaping technology planning and management. Discourse or communicative rationality is one of the foremost ways in which truth is socially constructed. Analysis on the relevance of discourses in information systems reveals that elements of the system design process can be interpreted as rituals that enable actors to emerge explicitly rational while negotiating to achieve their own private interests. Although there are varying types of rationality essential to the system analysis and design approaches, researchers on the subject maintains only one form of rationality. Communicative rationality is an idea of system rationality, which centres more on the development of mutual understanding and accord in the context of ideal speech situation. This theoretical situation is regarded as a social atmosphere that encourages everyone to speak freely and articulate his or her feelings. Embodied in information systems development methodologies are the principles of ideal speech, which treat system analysis and design as communication, and learning process thus, unfettering rationality is necessary to diagnose distorting communication tendencies (Cukier et. al. 2004, p.237). The positivist epistemology (a branch of philosophy that studies the validity of knowledge and belief) distinguish systems development as one of rationality whereas actions are acceptable on rational grounds and adhering to the proper organizational rituals. This was based on the assumption that information systems are designed to contribute to specific ends that can be articulated, shared, and objective. The resulting product of information systems development once completed and set up, the system itself will become an “icon of rationality” (Howcroft and Trauth 2004, p.198) that will improve the efficacy of the decision-making process by supporting various managerial practices. In system development rationality, information developers are seen as systems experts with rational thinking. They are assumed to have the ability to think clearly and solve abstract and complex problems with computers programmes. These programmes, tools, and other methodologies, which are often based on mathematical and logical processing techniques instead of human intuition, judgement, and politics, possess a characteristic of rationality. Consequently, the construction of information system will resemble a map of organizational reality in a more tangible machine-oriented level that would enable reengineering and transformation. While performing translation (human judgement to machine logic), developers are cautiously following structured techniques that would facilitate the separation of labour, provide audit trail, and generate a maintainable system. Finally, the completed information system will therefore become a product of the “embodiment of rationality” (Howcroft and Trauth 2004, p.198). 5.3. Effectiveness and Limitations of New Information Systems Development Approaches “Change is driven by uncertainty” (Erdogmus and Favaro 2002, p.2). For many years, computer application building is considerably lengthy and principally disorganized. The “code and fix” tradition and tedious methods of software development teams are frequently consequential to extended integration phase and various defects. Apparently, traditional Information Systems Development methodologies fail to deliver value and consequently, this failure has a large economic and human impact. One of the primary objectives of new or modern information systems development approach is to eliminate waste and to focus on real customer value. This is what Lean Software Development is all about. “Lean thinking” as developers call it, consider “inventory” of the traditional approach in software development a form of waste, a non-producing asset, and an artefact reducing responsiveness. Inventory incurs high administrative cost, as it requires storage and maintenance. It increases risk since nobody knows “how it will work until it actually does work” (Windholtz 2005, p.3) therefore, it cannot respond to the shifting markets. The 7 common waste of traditional software development according to Windholtz (2005) are: 1) Inventory – important features not yet in production and unnecessary intermediate documents. 2) Defects are not identified soon enough. 3) “Just in case” mentality resulting to over –production and elaboration of codes that is more often not use. 4) Extra Processing Steps 5) Time wasted on inquiries or getting the needed information by walking back and forth between cubes located on separate floors. 6) Idle time waiting for information to arrive 7. Transportation – handoffs, sign-offs, approvals The Agile Implementation of the Business model eliminates “Phased” development process as true customer value depends on the completed and functioning software and not on the generation of intermediate paper works (see Figure 1). Arose in the 1990s amidst chaos and bureaucracy of traditional software development (Windholtz 2005, p.1), the Agile Method of software development along with Extreme programming promises a new beginning for software development. It is a methodology and programming technique of short development cycles and diminutive release. It is considered people oriented and lightweight, well matched for small development projects. The main objective of this method is to improve the quality of software by solving the major predicaments in traditional software developments (Windholtz 2005, p.1). The following discussion will focus on the qualities, effectiveness, and limitations of Agile Development Methodology and Extreme Programming (XP). 5.3.1. The Agile Development Methodology The Agile Development method employs time boxed iterative and evolutionary development, adaptive planning, promote evolutionary delivery, and include other values and practices that encourage agility. While no agreement on what the concept of “agile” actually refers to exist (Abrahamson et. al. 2002, p.7), there is no exact definition of the Agile Methods as its practice varies depending on the application. However, Agile Development Method as far as advances in software development is concern, definitely stands for rapid and flexible response to change that is strategically highly manoeuvrable (Larman 2004, p.25). “Agile” is the name given to identify a family of processes featured inside a bigger software development approach called Lean Software Development, which include Extreme Programming (XP), Scrum, and Crystal (see Fig. 1). These processes have its own unique guidelines on how to organize and accomplish a programming work (Windholtz 2005, p.1). On the other hand, Agile Development Method according to Schuh (2004) is all about building software by empowering and having faith in people, recognizing change as a paradigm and encouraging invariable feedback (2). It is a “faster and nimbler software development process” (Abrahamson et. al. 2002, p.9). Overall, Agile Method is not the practice of development but the recognition of people as its primary drivers of project success backed by intense focus on effectiveness and manoeuvrability. 5.3.1.1. How Agile is Agile Development? The question regarding agility is best judge by its fast delivery that can shorten the life cycle of software development projects. For instance, Agile Development enables modularity in the development process level that can reduce the risk significantly. Its iterative approach with short cycles enables fast verifications and corrections during the development stage. Another is its time-bound with iteration cycles from one to six weeks and accompanied by its cost-cutting approach in the development process that eliminates all needless activities. Adaptable to emerging newer risk as its incremental process approach allows the building of application in small steps thus alteration due to sudden changes is trouble-free. Finally, its agile processes favour people over progression and technology thus encouraging concerted and unrestrained working style (Abrahamson 2002, p.14). The reality that the changing environment in software business affects the development process considerably; agile methods practitioners adopted the principle of satisfying the customer at the time of delivery over customer satisfaction at the moment of project initiation. This approach reduces developer’s uncertainties in the development stage, as they are able to concentrate more on the inevitable changes throughout its life cycle rather than worrying how to stop changes early in the project. Most developers using Agile method claims it can produce the first delivery in weeks allowing early win and rapid feedback. Since Agile Development technique encourages developers to invent simple solutions, there is less change and making those changes is a lot more convenient (Abrahamson 2002, p14). 5.3.2. Extreme Programming Extreme Programming or XP is a member of the Agile family of processes, which is part of the Lean Software Development. Every process in the Agile family has its own unique rules on how to structure and complete programming work (see Fig. 1). XP is about delivering to deadline, deploying programs to production in just a matter of weeks (Windholtz 2005, p.4)). Designed to work with projects than can be develop by smaller teams with a maximum of ten programmers, XP is a competent, frivolous, low-risk, flexible, and pleasurable technique in developing applications. It is capable of handling projects regardless of restrictions established by the current computing environment. It is diminutively adequate to do a test within just a few hours of the day. The idea behind XP is new but the process involve in its implementation are old and conventional. It is actually a compilation of verified facts and execution policies over decades of software development unified altogether in one methodology. In addition, to make certain that these procedures are adhered to, XP is designed methodically and every practices sustain each other to the furthermost extent achievable (Windholtz 2005, p.5). Extreme Programming practices unite the whole team on delivery of value and diminution of waste. During a normal working day, team members will conduct a fast 15 minute stand-up conference, obtain a story from the task board, pair-up, consult customer sitting with the team, hold programming episodes, monitor automated build and test system, and deliver a few fully tested integrated business stories. In XP, the expression “stories” indicates the most significant features from all potential business features calculated by cost and swiftness of the team doing the feature (Windholtz 2005, p.6-7) , (Chromatic 2003, p.62). The XP’s Episode cycle (see Fig. 3) commence with discussing the task to the user. Then the pair-up programmers will write an automated test for the particular task. This will usually takes about 10 minutes of their time until the test fails. With combined effort, they will try to write the code within 15 minutes using as much as possible, less line of instructions while ensuring test success. When the test does well, they will again clean up the code and try to enhance the design within 15 minutes. After this, they will then present their code to the source code control to test its integration competency and if it fails or become so difficult, they will throw away the code and perform the same cycle again. This approach is more practical that wasting their precious time solving a codes integration problem (Windholtz 2005, p.6-7). Communication, simplicity, feedback, courage, and respect are XP’s sets of values promoting optimistic working attitude. It is a development process taking advantage of cost reduction in software replacement by doing work a little at a time instead of spending too much time analyzing, planning, and designing for the distant future (Beck 1999, p.71) 5.3.2.1. How extreme is Extreme Programming? There are many XP differs from other software development methodologies in many ways. For instance, it uses short cycles as a replacement for the traditional and time-consuming long cycles. Its planning method is incremental thus; it is flexible and can quickly respond to the varying business needs. Programmers and customers are free to observe the evolution of development and identify defects early through its automated test method. Its evolutionary design process is significantly last longer than other methodologies. XP significantly augment close partnership in all stages of programming proficiencies and encourage practices that is suitable to the short-range nature of programmers and enduring concern of the project (Beck 1999, p.73). The XP’s exceptional set of values were place together to direct the programmers to work in the best interest of the project instead of their own short-range instincts, as short-range objectives often disagrees with long-term social goals. Since most disappointments in the project stems from not discussing important issues, communication is therefore essential to its success. For instance, critical designs changes are sometimes are not communicated to colleague by programmers and for some reason do not ask the customer the precise question vital to the project. In contrast, miscommunication in software development is real and does not happen by accident. XP’s objective is to keep the right communication channels open at all times and ensure the smooth flow of communication by employing several communication dependent practices that cannot be ignore by anyone. Unit testing, pair programming, and task estimation are examples of those practices that encourages compulsory communication between programmers and customers. However, this does not mean people cannot make mistakes or get distracted. XP is just making sure that this would not happen regularly (Beck 2000, p.23). Next is Simplicity with the aim to promote the creation of the “simple things that could possibly work”. Simplicity is the opposite of looking ahead in the future, which is definitely not easy to implement. People by nature tend to look ahead and worries about tomorrow. What will be next? What is out there? However, instinctively thinking ahead is listening to your own fears. As Beck (1999) explains, simplicity means, “do not try to solve problems you don’t have”. XP is relying on a principle that it is better to do simple things now and change it only when the need arises, instead of spending so much time building a complicated thing that may never be used. In addition, there is a mutual benefit between communication and simplicity because the more you communicate, the better you understand the things to be done and the more you are conscious about the things that you should not do. Furthermore, it is easier to communicate when the system is simple, as it requires fewer programmers (Beck 2000, p.23). Optimism in a programming environment is an occupational hazard and feedback is the treatment of such kind of threat. Specific feedback regarding the present condition of the system is invaluable. It works in a diverse time scales, minutes, hours, and days. Programmers have a minute-by-minute feedback regarding the current circumstances of the system. He can immediately check and estimate when a customer write new stories and send a concrete feedback to the customer about the status of their stories. The person in-charge in monitoring the progress of the tasks to its completion will later give his overall feedback to the team; this will give a complete picture of everything they planned to do in a specific period (Beck 2000, p.24). The primary strategy of the XP process is to prioritize the most valuable stories and put them in production as early as possible. Feedbacks from production will then give programmers an idea about the quality of decisions they made and learn from them. Other methodologies do not offer the same benefit since most of the programmers involve in the project will never see the system in production, and therefore ignorant of the quality of systems they created. This makes XP planning strategy the exact opposite of other strategies, which are normally keeping the system longer in development because of the prevalent belief that they can no longer make interesting changes when the system is already in production. Feedback, communication, and simplicity work together in harmony and assist each other during development. The more feedback, the easier to communicate, and the more you communicate the simpler the system (Beck 2000, p.26). In the same way, courage in XP represents the ability of a development staff to make concrete decisions. Throwing or tossing away a code (see Fig. 3) or a day’s work takes courage. XP encourages programmers to assess their codes usability, if a code is out of control then better toss it away and start again. It is better to start from scratch but clean and simple instead of persistently debug the code. This is a design strategy similar to a hill-climbing algorithm. However, the problem with this algorithm is reaching local optima, since only large change can improve the circumstances. It is important to have the three values in place for courage to work otherwise it would be just plain “hacking” (Beck 2000, p.25). Courage works with communication because it allows the prospect of a high-risk, high reward test. Simplicity invites courage because you will have more courage dealing with a simpler system than a large and terrifying complex one. Concrete feedback adds more courage as you will feel safer knowing the truth and will try drastic changes whenever possible (Beck 2000, p.24-25). 5.3.3. Assessment of Effectiveness and Limitations Risk is the foremost predicament of software development. Schedule slips, project cancelled, system fails in a couple years, software defect rate too high, software created didn’t matched the business needs, software features that do not have any business value, and development staff sudden turnovers (Beck 2000, p.10) Agile Development and Extreme Programming works on the same principle as they both under the Lean Software Development Methodology. Eliminating waste of the traditional or “phased” development methodology is the primary advantage of these modern development methods. They are theoretically ideal and economical in the sense that they can actually reduce cost and risk when implemented correctly. However, there are some points that we must consider before adopting these methodologies. Although Agile and Extreme Programming is conveniently accessible and easy to learn, putting their elements in real-life situation and keep them balance seems difficult. For instance, theoretically, these elements are supposed to work hand in hand and support each other but in the real world, unexpected things like fears, errors, jealousy, failures, and other human weaknesses do happen than can throw the whole process off balance. Some people may argue that solving these predicaments is just a matter of putting a supervisor who will control the programmers and keep them well spirited. However, aside from additional cost of development caused by additional personnel, there is no guarantee that the whole process will remain stable throughout the project cycle. Furthermore, many programmers may find it so difficult to acclimatize to this new development environment as it is entirely opposite of what they are doing all their life. Apparently, the problem here is not programming or coding but the change in the value system. People are naturally proud of accomplishing difficult task at work and since the principle of Agile and Extreme programming opposes complexities and promotes development of simple codes, programmers will soon experience monotony and possibly quit. Another possible predicament is collaboration, since programmers have to learn other people skill while interacting as closely with his assigned team. He must put aside the significance of individual thinking and accomplishment, and be dependent on feedbacks. Consequently, erroneous feedback caused by sudden frustration of a team member would generate performance degradation affecting the whole development sternly. According to Beck (2000, p.88), business culture is the biggest problem facing these modern development methodologies, as customers will normally insist on complete specification, design, and whatever documents to help them make better decisions. Programmers on the other end will also insist on prioritizing important features since they are trained to follow Agile and Extreme Programming principle. Subsequently, arguments and collision of principles between programmers and customers will occur delaying the development severely. Another culture related problem arising from Agile and Extreme development high speed but convenient timing principle is its unsuitability with companies requiring its employees to prove their worth by work long hours. Furthermore, these modern methodologies will not fit developers with inherent exponential cost curve. For instance, development in a Nth Mainframe requiring the same relational database but you are sure if it the right schema then Agile and Extreme Development is not for you. Modifying multiple existing applications is not “code clean and simple” and would only make things more complicated and inflexible (Beck 2000, p.89) Lastly, XP is noted for ignoring the value of documentation and it is only applicable to experienced developers (Fhruling et. al. 2005, p.4) In general, these modern methodologies are hard to do. This is the reason why many developers are unwilling to adopt the practice, as it would mean complex implementation and enormous disciplinary procedures. Moreover, customer constant involvement in the development is an idea most developers fear, as this will add tension and more responsibility to them. Finally, the limited size of projects that Agile and Extreme methodologies can accommodate is a big disadvantage that could discourage any serious developer from utilizing such method. Agile and Extreme Development is only effective to a certain extent and if a developer is willing to take the opposite direction in software development. Using such modern but demanding methodology requires extreme discipline and change of values and therefore only effective on case-to-case basis. Overall, although there are many negative areas in these methodologies, its effectiveness is theoretically ideal and promising. The only problem however is the willingness and inherent human weakness surrounding its actual implementation. 6. Conclusion Rationality in software development methodologies is for people involve in the process. This arises from the principle that actors in software development should think logically and rationally at all times as the success of the application depends on how it was planned and built. However, since human imperfection and other external factors tend to interfere in decision-making, tools and technique were developed to aid developers in their work. Making the right decision through communicative rationality enables ideal speech and mutual exchange of ideas resulting to near perfect choices. Although there are some opposing views about human rationality such as incapacity to recognize the truth and the effects of personal opinion and interest, rationality appears to have more value and advantage over decisions made without it. In relation to modern software development methodologies such as Agile Method and Extreme Programming, being rational is one of the key concepts of people-oriented development approach. This is in view of the fact that modern methodologies are more logical than traditional approach. For instance, cost cutting through short cycles and prioritizing significant features of the application is clearly rational than the time-consuming, nonflexible, and risky approach. The agility of Agile Development apparently comes from its inherent fast delivery of applications. Its unique approach to business model where true customer value relies on the delivery functioning software instead of intermediate paper works truly represents agility in development. Moreover, iterative approach with short cycles is a big advantage as developer can verify and correct errors swiftly during the stage of development. Agile is time-bound that cannot exceed six weeks and therefore fast and predictable. Its incremental processing and application building through small steps where alteration is conveniently possible, is probably the most responsive feature of Agile since it is adaptable to emerging newer risk. More importantly, let us not forget that Agile favours people over progression and technology enabling collaborative and unrestrained working mode. Extreme Programming is ideal for small project as there are indications that it is not capable of serving the needs of complicated computing set-up and various company policies. It extremely disciplined development atmosphere is not suitable for programmers whose values and working attitude are still traditional. Developers and programmers will probably feel useless when they put their individual thinking aside and just rely on feedback. Another important problem with Extreme Programming is business culture that nobody can change overtime. Applying the principle of XP will surely create tension between two opposing culture and consequently delay the development considerably. Lastly, even with uncertainties and apparent implementation problems, Extreme Programming theoretically is ideal and might work if the area of implementation is willing to accommodate the new principles of development. 7. Bibliography Abrahamson et. al., 2002, Agile Software Development Methods: Review and Analysis, VTT Publications 478, ISBN-951-38-6010-8 Broome John, 2004, Does Rationality Give us Reasons? Oxford University Computing Services, 13 Banbury Road Oxford OX2 6NN England Biderman Shlomo, Scharfstein Ben-Ami, 1989, Rationality in Question: On Eastern and Western Views of Rationality, Published 1989 BRILL, ISBN 9004092129 Beck Kent, 1999, Embracing Change with Extreme Programming, Cover Feature, First Class Software, October 1999 Beck Kent, 2000, Extreme Programming Explained, Addison-Wesley, United States of America, ISBN: 201-61641-6 Carew Peter and Stapleton Larry, 2005, Information Systems Development: Advances in Theory, Practice, and Education: Towards a Privacy Framework for Information Development, Published 2005 Springer, ISBN 0387250263 Chromatic, 2003, Extreme Programming Pocket Guide, Team-Based Software Development, O’Reilly-2003 Cukier Wendy, Bauer Robert, Middleton Catherine, 2004, Information Systems Research: Relevant Theory and Informed Practice: Applying Habermas’ Reality Claims as a Standard for Critical Discourse Analysis, Published 2004 Springer, ISBN 1402080948 Davidson Donald, 2004, Problems of Rationality, Published 2004 Oxford University Press, ISBN 0198237553 Erdogmus Hakan and Favaro John, 2002, Keep Your Options Open: Extreme Programming and the Economics of Flexibility, Chapter 43, Published in: G. Succi, M. Marchesi, L. Williams, D. Wells: Extreme Programming Perspectives, Addison Wesley, 2002 Fruhling Tyser and Vreede, 2005, Experiences with Extreme Programming, University of Nebraska at Omaha, College of Information Science and Technology, Proceedings of the 38th Hawaii International Conference on System Sciences – 2005, 0-7695-2268-8/05/ (C) 2005 IEEE Howcroft Debra and Trauth Eileen, 2004, Information Systems Research: Relevant Theory and Informed Practice: The Choice of Critical Systems Research, Published 2004 Springer, ISBN 1402080948 Kecmanovic Dubravka and Janson Marius, 2002, Information Systems Development: Advances in Methodologies, Components, and Education: The Rationalization of Organizational Life-The Role of Information Systems, Published 2002 Springer, ISBN 0306476983 Larman Craig, 2004, Agile and Iterative Development: A Manager's Guide, Published 2004 Addison-Wesley Professional, ISBN 0131111558 Muthoo Abhinay, 1998, Rationality in the Face of Uncertainty, Published in The Elgar Companion to Consumer Research and Economic Psychology in 1999, Department of Economics, University of Essex, Colchester CO4 3SQ, England, UK, November 1998 Parfit Derek, 1982, Personal Identity and Rationality, Synthese 53 (1982) 227-241, Copyright © 1982 by D. Reiclel Publishing Co., Dordrecht, Holland, and Boston, U.S.A. Roger Trigg, 1993, Rationality and Science: Can Science Explain Everything? Published 1993 Blackwell Publishing, ISBN 0631190376 Samuels Richard, Stich Stephen, and Faucher Luc, 2004, Reason and Rationality, Handbook of Epistemology ed. by I. Niiniluoto, M. Sintonen, & J. Wolenski (Dordrecht: Kluwer) 2004, Pp. 1-50, London Schuh Peter, 2004, Integrating Agile Development in the Real World, Published 2004 Charles River Media, ISBN 1584503645 Windholtz Mark, 2005, Lean and Agile Programming, Introduction to the 2nd Edition of Extreme Programming, Objectwind Software Ltd. Read More