Is this terrific advice for project management, and computer programmers generally ?

"The Hindu Upanishads speak of three types
attitudes - Satwa Guna, Rajo Guna and Tamo Guna.
Rajo Guna means excess thinking than what is
needed. Projects with over confidence are the most
susceptible to unexpected damage. Tamas means
darkness. Tamo Guna person can not assure any
thing. He treats things as if they are dreams. At
times, he goes through extremist methods to make
his projects successful - like the adventures in
dreams. Satwa Guna person keeps his confidence on
practicality. He goes through all details allowing
negative and positive possibilities. He speaks of
the viability of the project but never assures
with full confidence. He is successful most
of the times.

In a world of n number of unexpected and unknown
possibilities, how can any one be absolutely be
confident of his project?"
(info supplied by Yahoo answerer)

No one can ever predict the future with absolute certainty. However, people who project confidence tend to get business contracts and such. That is why there are salesmen and there are programmers.

The programmer's job is to report reality to the project manager, not not blow sunshine up his a**. It's the manager's responsibility to deal with the clients or whoever he is reporting to.

I do like the example of the second person in the parable, the one who lives in dream world. As a programmer, it can be hard not to focus on perfecting one tiny detail when there are higher priorities that need your attention.

By testing it against reality.

Anyone can be over confident. The Titanic was built as the unsinkable ship. So confident were the Protestants building it in Ireland where the Protestants and Catholics were at odds that they numbered the ship NO9093 which when looked at in the mirror says 'NO POPE'. The number was also out of sequence. That is not only how it can happen but also the result of over confidence. I'm not convinced the Upanishads hold any more water in the problem than any other religion or high floating sinkable.

Confident for what guarantee, for what amount of time, under what conditions. Existence is changing contingently.

I would eliminate the Tamas

i guess so

Relevance of what you say depends on the nature of the project, and experience of the personnel with the materials and data involved in the project.

Assurance is in quality of testing.

I am working on something right now in which the end users have keyed in a variety of dummy data, and we're checking out how that data shows up on a variety of reports, and inquiries, some modified to handle a new scenario & in some cases using standard unmodified software to explore clarity of the new data structures.

When things later go haywire, in my multi-decade programming experience, it is usually because:
* the testing was inadequate
* persons designing the testing had a inadequate understanding of the complexities of the system
* there was an el typo some place in the coding that generated bad results under circumstances not included in the testing
* the test data base contained copies of valid data, including private data like social security #s ... when we test, it is because we want to find out if anything is going to go wrong, we expect things to go wrong, so we can see what needs to be fixed ... thus it is dangerous to include data in tests that we would not want to be breached, like social security #s of real people
* programs are developed based on business circumstances or business rules as they exist at the time of their creation, then the rules change, the business evolves, and it does not occur to the people mired in those rule changes, to consult with the computer staff about any possible consequences where the programs assume the old set of rules, but the business is now operating by a new set of rules
* software is developed and tested based on the employees having a certain level of education in the business, and being involved in the development and testing, so they have a great understanding of what it is supposed to do, and how to use it properly. Then there is personnel turn-over, to new people whose understanding and familiarity with the software is severely lacking, and the training they get is incomplete or flawed
* a project is started which runs into complications, takes longer than expected to implement, the resources do not match the needs, decisions are made to cut back on how ambitious the project was, so as to deliver something that is "good enough" ... when there are such crunches, sometimes what suffers is the quality of the testing or documentation

yes...