The Fallacy of Perfect Knowledge by: David Wood
(Image source: basicknowledge101.com)
(Image source: Google.com)
"My previous works are not only applicable to one subject matter. I selected a few which are relevant when starting a project, a business, profession or a decision in life. It is important that we take steps carefully based on intuitive, intelligent and detailed planning."
We all know in our heart of hearts that we don't know everything. Every day we hopefully learn a bit more about our profession, our society and ourselves. But we simply can't know it all. If we stop learning we fall behind rapidly, especially in the software industry. The idea that one can apprentice to a trade and practice that trade the rest of one's life has gone the way of the dodo. Remember the dodo? No? That's the point.
Technology, techniques and the ideas upon which they are built change far too rapidly in our era for any practitioner to know all they need to know at any point in time. We must constantly learn and we must equally adjust to a state of ignorance, which requires us to spend some portion of every project researching the knowledge we need. Why, then, do we persist in pretending that we must, or even can, know everything about a software project during its development phase?
The history of software engineering is replete with attempts to control software projects, through carefully bound development and maintenance activities to prevent buggy, failed software. Most such methodologies, such as the classic "waterfall" methodology, presume that with sufficient time and up-front diligence a software project can be completely understood. Many demand that requirements be set in stone before a line of code is written. What nonsense!
Giving up on knowing it all during development, we might think that we can know it all later. Several software development methodologies presume this, such as the spiral or agile methodologies. Iterative development is seen as the key to delivery of a software project encoding "final" requirements. Unfortunately for adherents of those methodologies, delivery of a software project is just a comma in development, not a period.
Requirements, even when "agreed" upon in detailed up-front design, will change during development. It is impossible to know them all in advance. Multiple requirements often result in inconsistencies, even when they are gathered from a single source. Requirements may even mean different things to different people. Differing interpretations may be due to perception, goals. or language. In order to create a successful software project, we must accept and even embrace these ideas. We do not know it all and we never will.
The Fallacy of Perfect Knowledge is the delusion that it is possible to capture complete, non-conflicting requirements for a software project. The reality is that requirements will never be fully known at any time during a software project's lifecycle; not during analysis, development, maintenance nor even (or especially) when the system becomes legacy.
Continuous use of the agile techniques of iteration and refactoring into the maintenance phase of the software lifecycle begin to address some of these concerns. A fuller understanding of the ways that software evolves may be the next step. Until we have those conceptual tools, use them daily, and accept our ignorances big and small, we will continue to fall victim to the Fallacy of Perfect Knowledge.
―Until we have those conceptual tools, use them daily,
and accept our ignorance big and small,
we will continue to fall victim to the Fallacy of Perfect Knowledge.‖
WHAT I EXPECT TO LEARN:
How do I avoid being a victim of the fallacy of perfect knowledge?
(Image source: Google.com)
The fact that we should know everything that comes our way, is indefinite because we cannot
always remember everything in our mind. But it is very important that we always be aloof with
the changes because it is really the great deal of continuously learning and be able to get on the
road with the
right knowledge important for the chosen profession, to be able to contribute to our
society and most of all we learn for ourselves own welfare because if we stop learning we won't
be able to accomplish the goals in life and the choice of failing is only the choice you want to go.
(Image source: interns.org and theblueprints.org respectively)
New approaches, techniques and technology that plays the role in modernization are the reason
why we need to be able to handle ideas necessary for the needs of the certain entity which is
always constant. That is why researching is always required for everything that you are going to
do it is because most of the people pretend that they know everything when it is in developing
stage but your knowledge is not always enough.
(Image source: kellyservice.us)
So as many projects are made they are bounded with requirements, maintenance activities,
prevent bugs and worst is a failed software. Presume that with sufficient time and up-front
diligence a software project can be completely understood. Many demand that requirements be
set in stone before a line of code is written. This is total non-sense we say.
Because we want to know it all in advance but even those that are agreed upon are changed at an
unexpected twist in a project. With perceptions, goals and language these are the important
things that should be embraced to become successful in a project.
(Image source: jpcustomsoftware.com)
Iteration and refactoring is part of maintenance (even in other nature or fields). Software evolves so fast that the right conceptual tools, are used daily, and learn to accept our fault either small or large. We will continue to fall victim to the Fallacy of Perfect Knowledge but the right mix of preparedness and continues growth is essential to minimize the tendencies that comes in every step of the process.
(Image source: google.com)
WHAT I LEARNED:
I learned the you cannot always be right when you apply your knowledge
(1) ARTICLE ABOVE IS FROM 97 Things Every Software Project Manager Should Know
(2)THIS REVIEW IS AN EXCERPT FROM MY BOOK. THIS IS EXCLUSIVELY LICENSED UNDER CREATIVE COMMONS