 A software methodology is the
set of rules and practices used to create computer programs. A heavyweight methodology has many rules, practices,
and documents. It requires discipline and time to follow correctly. A lightweight methodology has only a few rules
and practices or ones which are easy to follow.
In the late 1960s and early
1970s it was common practice for computer programmers to create software any way they could. Many programmers excelled
at creating software too complex for anyone to understand. At that time it was a miracle if a program ran without
any bugs. Making computers useful was considered a worthy quest and not unlike an adventure into the old west.
In 1968 Edsger Dijkstra wrote
a letter to CACM entitled GOTO Statement Considered Harmful. The central ideas of software engineering were
being born. At that time we believed that bigger, more disciplined methodologies would help us create software
with consistent quality and predictable costs. The lawless cowboy coders were being reined in. |
The 1980s were good times for
computer programmers. We had a few rules and practices to create software that was far superior in quality to what
we were creating only a few years earlier. It seemed like if we could just create enough rules to cover the problems
we encounter we could create perfect software and be on time. We added more and more rules and practices to cover
all the potential problems.
Now in the 21st century we
find these rules are hard to follow, procedures are complex and not well understood and the amount of documentation
written in some abstract notation is way out of control. Trying to come up with a bigger and better methodology
was like a California gold rush; everyone headed west only to be disappointed.
Continued
on Page 2 
|
