| By Larry McCay | Article Rating: |
|
| July 2, 2004 12:00 AM EDT | Reads: |
19,353 |
article.getIntroduction().toString();
Comparing software development to manufacturing has been ingrained in the industry for years. This has led to such concepts as software factories and the commoditization that is currently sending much of the industry offshore.
The Scientific Method is a better analogy for the development of complex and evolving software systems in that it leads to a methodology that evolves software systems in such a way to make them more general and true over time.
This article describes how the Scientific Method supports the Extreme Programming methodology practices prescribed by Kent Beck in eXtreme Programming Explained.
The intent of this article is to illustrate the ways in which Extreme Programming is supported by the proven practices and guidelines of the Scientific Method, not to be a comprehensive guide or introduction to either methodology.
article.getMotivation().toString();
Having recently read Neal Stephenson's novel, Quicksilver, I've enjoyed a renewed interest in all things scientific. While reading an Isaac Newton biography, it dawned on me that the Scientific Method used by the scientific community in its search for knowledge, and taught to us as early as grammar school, is indeed analogous to the goals and very tenets of Extreme Programming (see Figure 1).
After a bit of googling, it becomes obvious that I am not the first to draw these conclusions. Rick Mugridge wrote a terrific paper that describes the commonalities between the Scientific Method and Test Driven Development (TDD), which happens to be a practice of XP.
In addition, I have never been comfortable with the connotations associated with the unfortunate name of Extreme Programming. It makes a hard sell even more so in some circumstances. Especially since the dot-com bust, management is leery of anything considered remotely extreme - let alone named "extreme."
extremeProgramming.getHistory().toString();
In the beginning there was Smalltalk and the Smalltalk culture or way. This culture included such things as refactoring, development in pairs, rapid change, constant customer feedback and integration, iterative development, and constant testing as key elements. This culture and technology date back to the mid-1980s at a time when Kent Beck and Ward Cunningham worked for Tektronix.
In addressing what he saw as the basic problem with software development - risk - Kent Beck developed Extreme Programming. Extreme only in the way that it applies common-sense principles and practices to the development of software. The fact that programming is part of the name is due to the code-centric nature of the methodology. Communication, documentation, and training are facilitated through the code - especially through the test cases used to drive the development process.
Being a lightweight software development methodology geared for small-to-medium-sized teams, XP's strength is in dealing with vague and/or rapidly changing requirements.
XP builds on best practices such as unit testing, pair programming, and refactoring.
The basic principles of XP are:
- Communication
- Simplicity
- Feedback
- Courage
- Choose a story.
- Write tests.
- Run tests.
- Refine, program, and refactor - repeat #3 as needed.
- Go to #1 until all stories are complete.
The Scientific Method was first introduced by Francis Bacon (1561-1626); however, it was not used as a strict discipline until Isaac Newton later in the 17th century.
The goal of the Scientific Method is to provide a set of steps to ensure the development of provable theories that may lead to new and/or greater understandings of the workings of nature and its systems. These theories are gradually stepped up in generality until the highest level, at which point there may be opportunity to unify the theories.
In his First Book of Aphorisms, Bacon asserted that:
There are and can be only two ways of searching into and discovering truth. The one flies from the senses and particulars to the most general axioms, and from these principles, the truth of which it takes for settled and immovable, proceeds to judgment and to the discovery of middle axioms. And this way is now in fashion. The other derives axioms from the senses and particulars, rising by a gradual and unbroken ascent, so that it arrives at the most general axioms last of all. This is the true way, but as yet untried.
Both ways set out from the senses and particulars, and rest in the highest generalities, but the difference between them is infinite. For the one just glances at experiment and particulars in passing, and the other dwells duly and orderly among them. The one, again, begins at once by establishing certain abstract and useless generalities; the other rises by gradual steps to that which is prior and better known in the order of nature.
To accomplish this, a methodology would need to remove any bias of the scientist from the experiment that leads to the proving or disproving of a given hypothesis or theory.
The Scientific Method consists of the following steps:
- Make observations.
- Create hypotheses.
- Make predictions.
- Conduct experiments.
- Modify hypotheses if predictions are not met and go to step 3.
- Declare hypothesis as theory.
programming.equals(theoryBuilding);
The Scientific Method is concerned with the generalization, unification, and development of Theories to express the workings of the universe and its components. Much of what comprises the Scientific Method is related to supporting this goal.
Peter Naur published a paper in 1985 entitled "Programming as Theory Building." His contention is that software development tools or methodologies cannot solve the inherent problems of software systems development alone. Naur prescribes the notion of programming as building a theory for the solution of the problem being solved by the project. This provides a greater understanding of the source code and system architecture and leads to a longer life for the system.
According to Peter Naur, programming itself may be viewed as an act of Theory Building. In viewing software development as Theory Building, a development team is focused on building, understanding, and communicating the theory of the solution to a given problem. One of the artifacts of the development and maintenance of such a theory is a computer program that is easily extended and modified by a group of developers that understand the original development team's theory of the solution.
Extreme Programming builds on Naur's concept through the use of the Metaphor in communicating and the continuous development of the architectural aspects of the program.
The common goal of a communicable theory across software development and the Scientific Method provides a jumping off point for discussing how the Scientific Method supports the extreme programming method of delivering software projects.
Just as any new introduction or change in scientific theory must retest and prove previous theory validations, in Extreme Programming enhancements must not break any of the existing unit or functional tests. In this way, the tests provide a mechanism to not only prove the integrity of the solution but aid in communicating the original and ongoing theory of the solution. Previously valid tests or experiments that no longer hold true in light of new developments may signify a need for change or dismissal of the original theory or solution.
pairProgramming.equals(peerReview);
The practice of Pair Programming within XP is a form of real-time code review. Its intentions are to facilitate the communication of important design decisions, catch violations of the chosen metaphor, or point out simpler designs and possible areas to refactor.
The Scientific Method must ensure the quality and integrity of the resulting data for public use - this is done through Peer Review. Peer reviews consist of a critical review by technical experts who don't have a vested interest in a particular investigation. The purpose of a peer review is to confirm that the research has been conducted in a scientifically sound manner.
story.equals(observation);
The development of user stories within XP is crucial in the collection of requirements and the understanding of the problem domain. The onsite customer and the clear communication and feedback between him or her and the development team is arguably the most important tool for the development team. Using this tool the developers are able to make the most accurate observations of the problem at hand, much the same way that scientific research requires accurate tools to collect observations that drive the development of the hypothesis to be proved.
Unit and functional tests are developed to determine the state of the delivery at any point in time. These tests are continuously run so as to catch any change in the integrity of the system. Once all of the tests are run successfully, the system is complete as described by the user's stories. This complete set of stories and tests document the theory of the system.
Using the scientific method, predictions are made based upon the observations that support the given hypothesis. These predictions are verified through unbiased experimentation. Based upon the results of the experimentation, predictions and/or tests are changed until the hypothesis is proven or disproven. If proven, the hypothesis may go on to be declared a Scientific Theory.
simplicity.equals(occamsRazor);
One of the core principles of XP is that of simplicity. "Which is the simplest thing that could possibly work?" The simpler the implementation and design, the easier it will be to test and change. This leads to designs and implementations that are more flexible, understood, and longer lived.
Occam's Razor is a principle proposed by the fifteenth century philosopher, William of Ockham, that leads to the practice of choosing the simpler of two theories that explain the same phenomena. This does not necessarily mean that the simpler of the two is more likely correct, rather that the simpler of the two is more easily tested.
article.getConclusion().toString();
To arrive at the best solution or theory for a given problem, scientists and software developers alike must adhere to certain practices that support the continued testing, evolution, and discarding of previous works.
The Scientific Method and Extreme Programming methodologies are practices that support these concepts.
Extreme Programming supports the notion of programming as theory building, which emphasizes the importance of the knowledge, communication, and understanding of the original development team.
But really, it's just a Theory.
article.getReferences().toString();
Published July 2, 2004 Reads 19,353
Copyright © 2004 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Larry McCay
Larry McCay is a Senior Software Engineer with over 15 years of professional software development. He currently works for Probaris Technologies, Inc., in Philadelphia and is a major contributor to the Probaris SP secure business process product. He is also involved within the JCP on security related JSRs. You can reach him at lmccay@probaris.com.
![]() |
DH Allingham 07/20/04 09:34:57 AM EDT | |||
This article brings to mind a phrase, "Me thinks the Lady doth protest too much.". Now think of this phrase in the context of "extreme programming" when any thing ''extreme'' is thought to be cool, hip, ''edgy''. But extreme programming is simply a codified version of Q&D (quick and dirty) programing, it''s been done for years. (Most coders have on a project that was run the same way sometime in their careers, think about it.). Coders like the environment since it does away with requirement analysis, design, and (shiver) system documentation. Some businesses like it for the quick turn-around times. But its a small project methodology no matter how you slice it. To me articles like this one that try to normalize it through a stretch of rationalizations only serve to push it from the realm of possiblity as a development option. Note the word option. |
||||
![]() |
dolthead 07/20/04 09:25:56 AM EDT | |||
I would love to "(see Figure 1)." Muchas lookas, no findy. |
||||
- It's the Java vs. C++ Shootout Revisited!
- Patterns for Building High Performance Applications
- OpenXava 4.3: Rapid Java Web Development
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Cross-Platform Mobile Website Development – a Tool Comparison
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- Three Buzzwords That Every CIO Hears but One They Should Listen To
- Immersing into JavaScript Frameworks
- Workday Reportedly Prepping to Go Public
- Book Review: Sams Teach Yourself Java in 24 Hours
- Cloud Expo New York: The Java EE 7 Platform - Developing for the Cloud
- Book Excerpt: Introducing HTML5
- Adobe Sends Flex to the Apache Foundation
- Five Years Waiting for JRE 7: Is It Justified? (Part 1)
- Book Excerpt: Java Application Profiling Tips and Tricks
- i-Technology in 2012: Five Industry Predictions
- It's the Java vs. C++ Shootout Revisited!
- Patterns for Building High Performance Applications
- OpenXava 4.3: Rapid Java Web Development
- The Next Web Architecture
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Is Write Once Run Anywhere Ever Going to Be a Reality?
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- JavaServer Faces (JSF) vs Struts
- The i-Technology Right Stuff
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- What's New in Eclipse?
- i-Technology Predictions for 2007: Where's It All Headed?




















