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”.
Quotes
"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."
Anonymous
"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