Had to look up Fibonacci. Have heard the term, even VAGUELY remember studying Fibonacci numbers wayyyyy back when. I even use the mathematical methodology in real life from time to time, but had forgotten that this term applied to it.

FizzBuzz I've never heard of, I'd have had to ask what the heck that was all about. Looked it up, once I knew what that term was all about it would've been simple enough to code a solution, in pseudo-code. In real code? Depends on what programming language you wished me to use.

As concerns the chicken question, you could expect to get a lot of questions from me. Asking you specifics about what goals you expected this chicken to achieve or fulfill. After all, my concept of what might constitute a perfect chicken are likely different from your ideas.

This last matter is crucial, and comes up virtually every working day of my life. In my working world, we write custom applications for customers all the time. Its what we do for a living, what we're paid to do.

We sit down with a customer and go over their goals and expectations, and seek out any specific requirements they may have in mind. Everything discussed is noted, and later formalized into a project "specification". Each point and item is discussed and clarification sought.

The point is, for our kind of work, custom programming under contract, it is not enough that the application just works and satisfies us ... the customer needs to to perceive that it works to their satisfaction in a way that suits their expectations and needs.

i.e. In the past we've had customers complain (and feel dissatisfied with the end product) over issues like "look and feel". Or user interface too complicated or ambiguous ... requiring too many keystrokes or mouse moves, not intuitive enough to the average USER, etc. Or entries are not made in a way already familiar to the end user. Or the application requires specific hardware (such as video capabilities) that aren't part of every machine the app is expected to run on. Info isn't presented in a style of presentation the end users are familiar with and find easy to scan, read, understand. Etc ... endlessly on.

My point is, in the past we've made perfectly good software, that performed technically perfectly a certain task or set of tasks. But which did not leave the customer with a good taste in their mouths.

Not good if you're doing custom programming and hoping to do future work for the same people. Or hope to have them recommend you to their associates.

Of course, when we're going through all this stuff and defining project specifications, here and there we DO offer suggestions, point out possible problems with the customer's ideas. Offer possible improvements, and explain why, which the customer can consider.

But in the end, the app must not only work, it must work in such a way as to suit the customer's wants and needs. In short, it must not be simply a chicken, but the kind of chicken that would make the customer think it's the best chicken to be had, in THEIR opinion.

Just some thoughts.

BTW ... we do get them to sign off on those specifications. Just in case. We're produce EXACTLY the kind of chicken they defined. And in the end if they're not happy, we're gonna charge to make changes.

Most times. In the real world we do have repeat customers with whom we've had a long standing business relationship, and from whom we've made significant money over time, who we toss a "freebie" from time to time. (Add a feature or modify something for free)