Without feedback from your sense of balance, riding a bicycle would be impossible.  You start to fall left, so you steer slightly left to "catch" your fall.

First, a basic introduction, then some examples and discussion on how this is relevant to many more things than just designing electronics.

http://en.wikipedia.org/wiki/File:Basic_concept_of_Kalman_filtering.svg <-- it says:  http://cs.brown.edu/stc/education/course95-96/Kalman-Filters/kalmaa43.gif

'''What sort of feedback?'''

Well in the general case, any. Allow me to introduce the concept with an example of a nice linear system.

The "operational amplifier" is an analogue electronic circuit component, generally on a chip. It has a huge "open loop" gain, and can amplify its inputs by a factor of a million or more.  It is almost always used in a negative feedback mode in order to limit the overall gain to some desired value, or do some other clever trick. The feedback is the control that stops the thing trying to run away to infinity (limited by the supply voltage of course); it lets the output settle.

This is a classic example of a "system", and a fairly simple one at that. Engineering and physics degrees generally teach control of systems, and often start with opamps because they're cheap, not too fragile and simple to connect up.

The first obviously relevant hits, for the curious,

	* The theory: http://www-control.eng.cam.ac.uk/extras/Virtual_Library/Control_VL.html
	* The educational applets: http://www.jhu.edu/~signals/
	* I haven't found a good, concise intro to opamps. Most of the hits are PDFs. I lost interest, yell if you want more explanation.

'''Kinks in the system'''

Linear systems at low frequencies are easy to deal with. They follow the theory as perfectly as the precision of the components allows.

If you increase the frequency, the thing doing the work has less time to combine the "feedback on current action" with  the new input, and the problem gets more complicated.  You have to start worrying about response times and graphs of open loop gain vs. frequency.  Pushing the system too hard can cause it to become unstable.  Indeed, this can be exploited to turn an operational ''amplifier'' into an ''oscillator''.

There are more problems when you get out of the linear '''range''' of the output, e.g. when the input falls outside the '''domain'''. The output will generally clip, and the signal will be distorted.  This is the servo bottoming out at the end of its travel even though the sensor tells it push further out, or the programmer being unable to deliver the required code despite the project manager's praise or threats.

If the system is horribly non-linear, for example a weather system, you will find that you have entered the realm of ChaosTheory.  If the system is actually your project, you don't want to go there.

'''Control of time'''

Consider Zogg, who has been instructed by the tribe leader to spend 5% of his work hours, averaged over a month, researching sharper spears. He could spend exactly one day every four weeks doing research, but RealLife doesn't work like this. What if he has another bright idea on the following day? Or gets hungry during the research day and goes off to do some beta testing?

He's better off scratching each hour of research up on the wall, then checking each month that enough research has been done.

In this example, Zogg can do BigDesignUpFront in the much maligned "blind" mode, but he's probably doomed to fail.
So you could say ControlRequiresFeedback, but this is not necessarily true.  It often makes it easier though.

'''Control of people'''

As mentioned in GaveUpOnTelevision, http://www.whitedot.org/ explains just how powerful feedback can be. (Perhaps discuss on WhiteDot?)

'''Examples on or relevant to this wiki'''

	* Feedback is at the heart of ExtremeProgramming.
		* YesterdaysWeather, when applied to TaskEstimation.
		* UnitTest''''''ing, when applied to SoftwareQuality.  Near-instant feedback on faults allows the programmer to fix things while he has the relevant state SwappedIn to his mind.  We increase the stability of the system by decreasing response time.
	* ScrumProcess embraces the FeedbackIsControl idea, calling it EmpiricalProcessControl.
	* CollectWhatWorks
	* TooGoodForFeedback: the feedback has to stop when you reach TheEnd.
	* People are highly non-linear systems.
		* You'll know this if you've ever offended someone by inappropriate use of negative feedback.
		* HawthorneEffect
	* PerformanceWithoutAppraisal discusses "feedback" from management to employee, and the second page makes an important distinction between technical and colloquial uses of the word "feedback".  More concisely, ReviewIsNotFeedback.
	* BrokenWindow''''''s: when there are some broken windows, other things get broken much faster.

There are more, I know, but I can't think of them now.  Feedback is everywhere - ever tried writing or using a mouse/trackball with your eyes closed?

----
See also: FeedbackEffect