Digital Edition

Programming as theory building

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.

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."

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:

  1. Communication
  2. Simplicity
  3. Feedback
  4. Courage
Extreme Programming consists of the following steps:
  1. Choose a story.
  2. Write tests.
  3. Run tests.
  4. Refine, program, and refactor - repeat #3 as needed.
  5. 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:

  1. Make observations.
  2. Create hypotheses.
  3. Make predictions.
  4. Conduct experiments.
  5. Modify hypotheses if predictions are not met and go to step 3.
  6. Declare hypothesis as theory.
Newton, inspired by Descartes, believed in mathematics as the truest mechanism of proof. Through experimentation, Newton tested and proved all of his greatest scientific discoveries. Some of these experiments were used to prove the theories developed by earlier great thinkers such as Galileo.

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.

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.

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.

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.

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.


  • Beck, K. (2000). eXtreme Programming Explained. Addison Wesley.
  • White, M. (1997). Isaac Newton: The Last Sorcerer. Perseus Books.
  • Mugridge, R. "Test-Driven Development and the Scientific Method." Agile Development Conference, June, 2003.
  • Fowler, M. (1999). Refactoring. Addison Wesley.
  • Naur, P. (1985). "Programming as Theory Building." Microprocessing and Microprogramming, 15: 253-261.
  • Stephenson, N. (2003). Quicksilver. Harper Collins.
  • Portland Pattern Repository WikiWikiWeb. XpRoots:
  • About 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

    In order to post a comment you need to be registered and logged in.

    Register | Sign-in

    Reader Feedback: Page 1 of 1

    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.

    I would love to "(see Figure 1)." Muchas lookas, no findy.

    Subscribe to the World's Most Powerful Newsletters


    Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple ...
    "Cloud computing is certainly changing how people consume storage, how they use it, and what they us...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As au...
    In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the te...
    "We were founded in 2003 and the way we were founded was about good backup and good disaster recover...
    The now mainstream platform changes stemming from the first Internet boom brought many changes but d...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
    "We began as about five years ago as a very small outfit. Since then we've transiti...
    "DivvyCloud as a company set out to help customers automate solutions to the most common cloud probl...
    Enterprises are striving to become digital businesses for differentiated innovation and customer-cen...
    Apps and devices shouldn't stop working when there's limited or no network connectivity. Learn how t...
    "Outscale was founded in 2010, is based in France, is a strategic partner to Dassault Systémes and h...
    Adding public cloud resources to an existing application can be a daunting process. The tools that y...
    Organizations planning enterprise data center consolidation and modernization projects are faced wit...
    CI/CD is conceptually straightforward, yet often technically intricate to implement since it require...
    Let’s face it, embracing new storage technologies, capabilities and upgrading to new hardware often ...
    Fact: storage performance problems have only gotten more complicated, as applications not only have ...
    "We do one of the best file systems in the world. We learned how to deal with Big Data many years ag...
    "We are a monitoring company. We work with Salesforce, BBC, and quite a few other big logos. We basi...