Describe how you have reacted to a failure.

30 minutes to write this for the class final.

The difference between the wise man and the fool is not that the wise man succeeds at everything on the first try.  The difference is that the wise man only sees someone fail that particular way one time.

As a computer programmer I was often called upon to code solutions to problems that nobody at that company had dealt with before. Failure had to be factored into every project, and a solution to each failure found before the scheduled deadline. You couldn’t just look up the answer and implemented it. You first had to figure out exactly what the question was, because often the person asking for something wasn’t very specific about what they wanted.  This was called a functional specification and is a negotiation between everything that someone could possibly want, and what was technically feasible to implement in the limited time with the limited resources available.

Only once you knew exactly what someone was asking for could you write up a technical specification about how you would implement a solution given the limitations of your computing environment.  After 3-4 weeks you would have a good idea of the question and a solution to the problem and it was time to attempt to implement the solution.

Often this is where programmers like me would come into the project.  We would be handed the functional and technical specifications and told we had 4 weeks to implement the code.  We were told that this would be our number one priority, along with the dozen other number one priorities we also had at the same time.   

Often I would bring up the project at team meetings and get input from everyone there about how they would like the project to be implemented.  I would give my ideas on their projects as well.  Once I had an idea of how to implement the code I would break the code up into interfaces and code each piece.  If more than one programmer was working on the project we would each work behind one of these interfaces and if we did our piece correctly the code would just match up and run in a couple of weeks.

Now, we programmers expect to write the code completely wrong, so at each interface we would first spend a couple of hours writing the interface and a test harness to test the code.  The more time we put into this, the more robust the interface would be later.

Then we would implement the code behind the interface, in a fill in the blank way.  It was a cycle.  Write code, test it, see how complete and functional it is, repeat.  At this point it is common to run into problems, figure out a solution, and have to go back and amend the technical and functional specifications.  Sometimes the project is made longer to fix the problem.  Sometimes the project is broken into a phase I and II.  Sometimes everything goes right and you make the deadline with functional code that actually works.

You then go into testing.  Quality assurance gets the code and the specifications and tests everything.  We developers would get bug reports and fix the problems, rolling out new releases to test.

At the end of the project we always won, despite having numerous failures along the way.  Any system that doesn’t implement feedback to correct failure is a broken system.  Failure is part and parcel of life.  The only failure that counts is the failure that isn’t corrected.