Skip Navigation Links > Blog


Applying the scientific method to software development

The scientific method has been used successfully by the scientific community for hundreds of years. Since this method has been proven to work, let us approach the problem of developing a software system from the perspective of a scientist using the steps below.

1) Analysis: Observe, record, and study some aspect of the customer’s vision. From an engineer’s perspective the customer’s vision is the problem domain for which a solution must be found. The engineer must study the vision to "discover how it works" from a user’s point of view. Analysis is a discovery activity.

2) Design: Invent a hypothesis that explains the “observations” of the vision. A hypothesis is captured in the form of a model using UML notation. For the vision to work as observed there must be an underlying design mechanism. The engineer must therefore invent or reuse various possible designs that might be behind the observed behavior. Design is an invention activity.

3) Implementation: Implement the design model so as to transform the hypothesis into an executable form. The implemented design model must be deployed into the solution domain (i.e. the environment where the solution can execute) so that the hypothesis can be tested. Implementation is a construction activity.

4) Test: Verify the correctness of the implemented design model by comparing actual/computed results with the expected/predicted results. Next, use the model to make a new prediction of some observable aspect of the problem domain. Verify the prediction by designing, implementing and executing an experiment (a test case). If the new test case or a previously working test case fails then modify the hypothesis model as necessary until all experiments agree with the predictions. Collect test cases into test groups to form test suites. Collections of test suites form the basis for regression testing. Testing is a validation activity.

5) Evolution: Refine the model by repeating steps 1 through 4 until the difference between the customer’s vision and the engineer’s solution is deemed small enough to permit an incremental release. With regards to unit tests, only when 100% consistency exists between the hypothesis (in the form of the implemented design model) and experiment (the unit tests) do we have a release. This rule is very important since each incremental release serves as a trusted building block that may be used with confidence to create even greater complexity in the next release. In a development team environment a certain amount of overlap will occur between steps 1 through 4 at any given time. Evolution is a refinement activity.

A release developed in the manner described above would be considered by the scientific community to be a “theory”.



"Any complex system that works can be shown to have been derived from a simpler system that worked."
Grady Booch


"If debugging is the process of removing bugs, then programming must be the process of putting them in."
Edsger Dijkstra


"The impossible we do today - miracles take a little longer."


"The only thing more expensive than writing software is writing bad software."
Alan Cooper


"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
Antoine de Saint-Exupéry