Failure Oriented Approach

The opposite, non-existent approach as compared to SuccessOrientedApproach. One entered into deliberately with intentions of failure, and is never the goal of any individual, group, or organization, with a one or few exceptions.

When is the word "never" appropriate when it includes a few exceptions? Don't the exceptions change the meaning to "..is sometimes the goal"? I would suggest that any approach which does not include methods and processes aimed at a successful outcome of an accepted, clearly stated goal is not a SuccessOrientedApproach.

I don't think the description above adequately describes what a FailureOrientedApproach is. In my mind, it's an approach developed in stark reaction to failure. One that is meant to reduce liabilities in the most cynical way, such as pushing all the liability (and thus responsibility) onto the customer. I often claim that WaterFall was created in this way. One lawsuit after another, it has developed cruftier practices over the decades in order to prevent failed software projects from being sued. Traceability is liability, after all.

An example, (my source is Harvard Business Review, so no link) is Intel's antitrust policy. They avoid scrutiny from the U.S. Department of Justice because their antitrust lawyers conduct "antitrust raids" on business units, where they pretend to be government lawyers in the discovery phase. If they find anything, even a gung ho e-mail, the business manager is screwed. Apparently, after one failure to meet the company's requirements, most managers get back on the path.

This is failure-oriented because it is specifically created to address failure: a government antitrust lawsuit. The other descriptions on this page sound more like bitterness directed at failed approaches, but failure is not itself failure-oriented. -- SunirShah

An FailureOrientedApproach is not a reaction to an event, but rather the the lack of a planned sequence of execution (including people, material and schedule) . A project or a process must be defined either by way of planning, or by incremental evaluation of progress. One moves away from success by performing neither, For in having no means of measuring or accounting for effort toward a goal one has adopted a FailureOrientedApproach. What you do having failed, or when it appears you may fail, occurs because you have omitted goals or measurements or of accountability toward a completion. Itis on the part of developer as well as customers the lack of performance of contract responsibilities of proper project planning and orientation toward success.

Two illustration of this were experienced just today: The statement of a man who became responsible for a project, not having background or experience. He was simply told "Here is the company credit card; go buy the books and programs you need to complete this job." This has all the appearances of a FailureOrientedApproach. Another instance: A programmer with considerable experience in his field of expertise was told, "The client wants thus and such, can you do it?" The reply: "I don't know how and have never done this." The return, (same approach) - here is some money, make it so!

No, that can't be a failure-oriented approach, because the approach is not even cogniscient of failure. Which is precisely why it is failure oriented. One does not have to be cognizant of failure orientation to fail. It is the lack of cognizance of what it takes to succeed that leads to failure. When one is driving toward a destination to which a journey has never been made, and refuses to use instructions about how to get there, or to use a map, or to stop and get help from someone who knows, the orientation is toward failure. He may evolve the correct path by trying every possible road and turn, but frustration and weariness will probably set in before reaching the destination. It will probably get dark and the discovery of a successful arrival will not even be possible. There are definitely things we can do and things we must do to ensure success, these are the things that point us toward success. Refusal to apply oneself toward successful accomplishments is a failure orientation. Some people will never understand this, and are doomed to failure unless they get help.

There were clearly two people involved - one who was used to making things happen through others, and a second through which the success was to occur. Both utilized approaches which were not success oriented. The first in understanding, and the second in communicating. The first's did not understand that the second did not know how to accomplish the goal, and the second failed in communicating that a means of success was not within his own skill set, and that money and credit cards would not make it so and that the assignment should be refused on those grounds. Since the second did not refuse, the first assumed that it would happen.

Their approaches may be failing, but they aren't failure-oriented. Their approaches were not created with the intent of failing, and what else could define the orientation a method except for the intent? Let's return the word "orientation" to whence it came from. Consider a sailboat stern to bow pointing due north. It's orientation is north. However, strong currents are causing it to drift east. It's direction is east. Orientation is not the same as direction. So, in your example, while the direction of their approach is failure, the orientation is not. -- SunirShah

In the illustration, there are no external strong currents causing drift, the currents causing non-success are capable of being controlled or steered by the two participants.

This is not a valid objection. The "strong currents" are stupidity, lack of time, lack of communication skills, et cetera. These are all things external to the two people's approach to problem solving. If you claim these things are internal then everything becomes internal and the metaphor of 'orientation' towards some external goal becomes meaningless. IOW, either Sunir's distinction between failure-approach and failure-oriented approach stands or the entire concept of FailureOrientedApproach is nullified. It's up to you to show there is a third alternative. It is a valid objection, the use of the excuses of stupidity, etc, are just what makes the orientation wrong, the check on heading is necessary to determine true travel. An accepted goal is an internal goal, and a coerced goal is an external goal. Your approach and orientation toward goals that are not your own is another question.

I believe that people approach problems simply, one item at a time. I am fully cognizant of the complications in reaching success points in a process. It is not a two-dimensional problem. Nor can the solution be as simple as "if A is so then all things must be A". To state so is to introduce meaninglessness. An illustration is never the exhaustive demonstration of a concept as difficult as Success or Failure. In the case of the second illustration, the orientation is clearly a not a success oriented approach, since it has no components of success included. A desire for success exists in the attempt to assign to the "doer" the task, without making all of the components necessary for success available. See WhoIsInCharge for more discussion on this aspect. The failure of the "Doer" to decline the assignment of responsibility for results without adequate support is like pointing the bow of a boat to the North while riding on the back of a Semi Truck moving 70mph to the Southeast on Interstate 75, when the target destination is San Diego. It is a "Failure Oriented Approach" The vehicle is inappropriate, the initial conditions are not stable and suitable as a starting point, the skills of the navigator who is capable of steering a boat in water, finds those skills inappropriate in navigating on land. If you still fail to the point, I can furnish other illustrations which support the claim that any approach which is not focused on what it takes to reach the goal or target, is a not a "SuccessOrientedApproach".

Maybe you could begin by showing how the two boatsmen are not focused on their goal, instead of merely failing at their goal. Are you going to blame all failures on people being "not focused enough"? Can you even define "focused" or is it going to be an annoying weasel word? Focus is a clearly understandable word, it derives its meaning from optics, and vision. One is focused if one opens the eyes and looks upon an object. What is a weasel word? See WeaselWords.

The problem as we see it is that you're not leaving any room for distinction between failure and failure-oriented. And you seem to assume that success is always possible if people are motivated enough. It's perfectly reasonable to speak of behaviours as if people wanted to fail (because on some level, maybe they do) but lowering yourself to pop psychology in the endeavour is inadvisable. The application of pop psychology dogma is itself a FailureOrientedApproach if the goal is to understand human behaviour and motivation.

Failure is distinct from Failure Orientation. Failure to hit a target is distinct from failure to aim at the target. Focus is "looking" down a sight at the target.

My expressions are my own, not the result of Pop or serious Psychology. They are observations and aimed at accomplishment, not behavior and motivation. I assume that people are going to observe correctness in behavior and that motivation is for the greater good.

Your thinking about FailureOrientedApproach is FailureOriented? by your definition. It seems that your original goal was to define a SuccessOrientedApproach. But the negation of a success-oriented approach is not a failure-oriented one. It's simply a failing approach. A failure oriented approach is one where the goal is failure. Or possibly where there is an obsession with failure (which provides institutional incentives to people to cause failures.) Claiming that the negation of success is failure, never mind the negation of success-orientation being failure-orientation, is to warp language.

: I don't think there's anything to be gained by creating a definition for pathological cases where people are attempting to fail on purpose. I prefer my definition where failure-oriented means an approach created specifically to minimize failure. A SuccessOrientedApproach would, on the other hand, but one created specifically to maximize success. These aren't the same things. As I said, Intel's antitrust raids are failure-oriented. Performance bonuses are success-oriented. The example we're arguing here is neither. It's merely ignorant. It may succeed, it may fail, but the whole problem is that there is no orientation to speak of. I think your interlocutor continues to mince the distinction between ironic failure and intended failure. -- SunirShah

You claim that maximizing success and minimizing failure aren't the same thing. On the contrary, most people define success as averting failure. A simple example is a sysadmin trying to keep servers working. But on a fundamental level, averting failure is the principal human motivator so most people define success as averting failure.

What I think Richard is trying to say is that by being incompetent you obtain the highest reward. Let me explain. If you absolutely do nothing, you are fired. If you fix everything in 20 seconds, who needs you anymore? So you need to actively do stuff, solve things every day, while at the same time leave some things undone or poorly done for the future. Software examples: Windows 95, Windows 98. Windows ME was an AnUnacceptableWayOfFailing. As a manager you need to hire incompetent people to make sure the project fails, or at least the project's time is extended. It does not matter unless it is perceived as a failure. You get more bucks? That's hardly a failure. The project could be done in Java or in C? Then select C++ so that it takes twice as long and costs twice as much. It will look as a 4 years project instead of a 4 month project in your resume. -- PointyHairedBoss

I don't believe your assertion that most people equate success with avoiding failure either. You'll have to back that up with something other than pessimism. The whole nature of professional work is to accomplish something significant--to build something--not just to avoid starving, even if that's the pragmatic utility of working.

Maybe you're just projecting your own feelings onto others? Of course, if you're really clever, you'd dig up SoftwareIsReallyPointless to see why I might agree with you in the world of software. -- SunirShah

Example: "most people define success as averting failure" I disagree - taking a step as a goal - If you do not fall down, you're successful? taking a walk around the block - if you don't fall down 700 times you're successful? ItDepends on your PointOfView. Saying that success in writing code is avoiding failure is missing the point. Success is realizing the accomplishment of goals, not the avoidance of failure. When I write code that does what I want it to do, I consider it success. It is not considered success because it does not do what I do not want it to do. Success is the accomplishment through a series of single steps each of which when successful leads to a final success. Each line of code, each instruction, contributes to an accomplishment, they do not avoid non-accomplishment, each aha! moment brings one closer to success.

Another example of the difference between seeking success and avoiding failure comes from a Star Trek: TNG episode. Data is challenged by the Federation champion at a particular game. Initially, Data is defeated every time. Near the end of the episode, he plays a final match which his opponent calls off in disgust, calling it a mockery. Data explains that he changed strategy from attempting to win, to attempting to avoid losing - seeking to maintain a stalemate rather than win at risk of losing. Note that, while the outcome of his "failure oriented" approach is treated in the episode as a success, it's not in the terms of the original challenge.

AlanCooper argues that workers in their jobs are driven primarily by avoiding embarrassment. Of looking incompetent, of being told they're stupid, et cetera. He's used this one insight to advocate for software that communicates success instead of errors, makes failure impossible, and minimizes the costs of failure to the user. These principles make a lot of sense to me.

In the case of writing software, one of the practices advocated by XP is writing UnitTests before code. Once that is done, you've synchronized 'success' and 'avoiding failure' so can no longer distinguish between them.

A test is used as a success determinant. It is used to verify correctness of procedure, actions and results. Test are not written to verify failure, even though when exercised they might reveal failure. Tests are written to point out that FailureIsNotAnOption.

The inability to no longer distinguish between them is a serious problem of focus. To achieve success, one must focus on accomplishment. Planning takes place to fix focus on what is expected, what is available to achieve and what time is set aside for accomplishment. The best way to avoid failure is to be properly prepared for the challenges a task presents. To be obsessed with avoiding failure is to fix focus on not accomplishing. The fear of failure resides in the "ill-prepared", or with those who have accepted (or have been assigned) tasks for which either resources, time or capable manpower is not available for accomplishment.

But in the general case, software is so brittle that it results in failure almost all of the time. Following this insight, programmers are those few people who can focus on success and don't fear failure. A very small part of the population.

Software written so poorly that it results in failure almost all of the time will not be used. It is the successful and functional software that will be used. So when I apply tests, I test for success, not failure. I want to be sure ItWorks. It it does not succeed, I make it succeed, I make it functional, or I get another tool. If I am more concerned with being embarrassed by failure and concern for avoiding such appearance, I will not move forward with proactivity. The point of such tests is to confirm functionality and move on to the next task.

"So when I apply tests, I test for success, not failure." Could you please explain this, or at least explain in what way you think your methods differ from those of others? I write tests to verify "correctness". That when procedures are executed and when proper parameters are supplied, that an expected result occurs. I then move on to the next task. When it is completed, I submit it to the testing process. The focus is not on failure, but on verifying completeness and correctness. It is the way most programmers I know evaluate functionality. It is only different from those who seem to be concerned with being embarrassed by failure and whose goal is to avoid it.

How do those who are "concerned with being embarrassed by failure and whose goal is to avoid it" apply tests?

It it difficult to say, perhaps they will avoid, postpone or shift such responsibility to another programmer or manager who is better equipped to deal with and achieve Success.

I have come across at least two occasions where people have acted as if they were deliberately aiming to fail. In both cases, the person in question was in a position of high authority in a project, and had a very strong disagreement with its technical direction.

Although the person had lost the original argument over direction, they were never convinced that the approach was right. By passive resistance, they were (in both cases) able to leverage their power to effectively sabotage the project.

I believe most people would agree that this would be classified as AnUnacceptableWayOfFailing!

See