A Business
Perspective
(Evolution of
Programming Methodology, Part I , Page 4)
By Bill Nicholls
February 28,
2000
The
failure of SP to be the answer to all problems also
caused a recognition that the whole programming process was
far more complex than had generally been realized. A broader
perspective on the whole issue of delivering complex
software, its perils and pitfalls, arrived in an insightful
book, The Mythical Man-Month by Frederick P. Brooks,
referenced in my columns a number of times.
This book is important for a number of reasons. It was
written by a man who had full responsibility for controlling
the development of IBM's flagship operating system, OS/360,
in all its versions -- PCP, MFT, and MVT. The book contained
things to do and to avoid, and honestly reported numerous
lessons learned the hard way. The book taught lessons at all
levels from beginning programmer through upper management,
and had a substantial impact on practices in the industry.
It also stimulated further research into solving these
problems.
Most importantly, this book looked at programming outside
of the academic world and placed it in a business
environment. No longer was programming looked at as simply a
problem-solving exercise. It was clearly placed as part of a
business organization that had to meet such annoying
requirements as schedule, function and reliability.
Programming was now part of a system and the process
had to expand to deal with all of the human and business
issues as well as the technical ones. This large rock
dropped in the pond of programming has generated ripples we
see even today.
Teams
Another paper, "Chief Programmer Team
Management of Production Programming" by F.T Baker, explored
the approach of building a support team around one
super-programmer. This person would be responsible for
delivering the most difficult code. Other programming tasks
could be done by mere humans, who were in turn supported by
tool builders and librarians. It was a powerful concept that
stumbled on human hubris, as most programmers consider
themselves to be in the super class. But the team concept
and supporting people and tools have become a standard part
of the programming environment.
Teams rapidly evolved into small groups of programmers
with a team leader, who might not be the best programmer.
Work was usually aligned with skills, and good teams with
internal support between members could create working
programs very effectively. But when the job required
multiple teams and multiple years, communications problems
and turnover created invisible monkey wrenches in the works.
Another level of organization had to be added to manage
large projects, with project managers. Efforts at using
planning tools were unreliable at accurate forecasting
because many projects broke new ground for the participants
and their past experience was not effective at providing
good estimates. Changing specifications in mid-stream, tools
with hidden bugs, unclear communications, all took their
toll on productivity. It seemed that even the team approach
had reached its limits by the mid 1970s.
More To Come
In the next column, I will
describe the MVC concept and how it differed from earlier
concepts. Then the development of client-server, the
creation of objects, MVC again and finally, patterns. After
discussing the implications of what we have learned in the
past 40 years, I'll suggest a few possible steps for the
future. 
Bill Nicholls was
educated as a physicist, but early in his college career
became seduced by the computing side of the force. Since
then he has badgered mainframes, minis and micros into
mostly doing what he wanted, though with varying degrees of
difficulty. Software has always been his primary interest,
from writing an OS to applications. Don't ask him to do
another payroll though.
For more of Bill's columns, visit the Utility
Infielder Index.
<<<Previous
Page
