Hi Folks,

I'm currently reading a very influential and timeless book ("The
Mythical Man-Month" by Frederick P. Brooks, Jr. (he was project
manager for the IBM System/360 computer family and for OS/360),
http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959,
http://en.wikipedia.org/wiki/The_Mythical_Man-Month). I would like to
quote here a few paragraphs from the second chapter of the book with
some testing related wisdom:

"For some years I have been successfully using the following rule of
thumb for scheduling a software task:

1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hand.

This differs from conventional scheduling in several important ways:

1. The fraction devoted to planning is larger than normal. Even so, it
is barely enough to produce a detailed and solid specification, and
not enough to include research or exploration of totally new
techniques.

2. The _half_ of the schedule devoted to debugging of completed code
is much larger than normal.

3. The part that is easy to estimate, i.e. coding, is given only
one-sixth of the schedule.

In examining conventionally scheduled projects, I have found that few
allowed one-half of the projected schedule for testing, but that most
did indeed spend half of the actual schedule for that purpose. Many of
these were on schedule until and except in system testing. C. Portman
of International Computers Limited says, "When everything has been
seen to work, all integrated, you have four more months work to do".

Failure to allow enough time for system test, in particular, is
peculiarly disastrous. Since the delay comes at the end of the
schedule, no one is aware of schedule trouble until almost the
delivery date. Bad news, late and without warning, is unsettling to
customers and to managers."

And another quote, from the related wikipedia page:

"The tendency for managers to repeat errors in project development
(VJ: such as those described in the book) led Brooks to quip that his
book is called "The Bible of Software Engineering", because,
"everybody quotes it, some people read it, and a few people go by
it.""

It is amazing to see to what extent the wisdom of this book is still
applicable today, regardless of the enormous progress of hardware and
software development tools, processes and techniques for the last 40
years. Perhaps one of the reasons for this is that human elements of
software engineering don't change that much and that fast (if they
change at all). A lot of influential people think that software
engineering is an art, rather than a scientific endeavour...

Kind regards,
Vedrin