Consider any C# program for example, How will you start explaing that program... Friends of mine are really struggling to explain a program to their team members...
what is the best way to explain a c# program?
What is the major mistake done by developers while explaining a program to their Team leader?
If you are a team leader, what will you look for in that explanation from your team memeber?
Any tips for your team member about explaining a program?
I might be oversimplifying this, but this is how I would describe a program (in terms of your dot points)
Explain it's function. What does it do? What problem does it solve? How will this improve you working life? Being able to express it's usefulness will go a long way.
I don't have any first hand knowledge, but my suspicion is that developers promise to solve EVERYTHING with this program.
If I was a team leader, I would want to know what it is that going to be fixed, or improved or why I should invest money and time in this program.
Be succinct. If you can't explain the nature and benefit of your program easily and succinctly, then I wonder about the dedication (not quite the right word) behind the program.
Anyway, that's my thoughts on it. I suspect someone with more specific knowledge or examples can provide some other ideas.
A couple of things I found most useful - more than all the documentation, UML diagrams combined is a (non-functional) prototype app that "demos" functionality. I found one can crank something out, for even the most complex application, in a matter of a few hours. Alternately, you might want to create a set of wireframe diagrams.
I think these questions apply for any programming project in any language, not just C#.
1. What is the best way to explain a C# program?
With any program, I would give an overview of what the program DOES, in at most a few sentences. I would also explain every input and output of the program (gets input from a commmand line and outputs to a file, or gets input from a web page and outputs to other pages and the database). Then I would give an overview of the various components of the program -- UML diagrams help with this. From that point, I'd have the developers start looking at the code, and have them seek further clarification if necessary.
2. What is the major mistake done by developers while explaining a program to their Team leader?
Not being completely honest about the problems they're running into, or giving a real estimate on how long they think it'll take them to finish.
3. If you are a team leader, what will you look for in that explanation from your team memeber?
I'd want to know exactly what they're currently working on, if they're running into any problems, if there's any way that I can help them, and how long they estimate it'll take to finish what they're working on.
4. Any tips for your team member about explaining a program?
Give them the overview and any/all documentation, diagrams, etc., in a document or email. I find it very helpful if I've got a copy that I can read and reread as necessary, and refer to when discussing problems with the team lead.
In the team you described there's obviously a fundamental disconnect that needs to be discovered because your initial questions create more questions such as:
There's something deeply wrong with the scenario you describe. Can you provide more detail, maybe starting with some background. Change the names and places if need be. We might end up recommending a motivational coach for the perfect solution, or a book about how to get out of the mire of company politics.
While, imho, the original question (and even the sub-questions) are so broad they could be interpreted one-thousand-and-one different ways (a "Scherezade" question(s), if you will) ...
What jumps out at me, reading the question, and all comments/answers to date is : not one mention of comments in the source code.
If you are really describing a "real world" application development scenario with some complexity (it is not possible for any one team member, or even the project manager(s), to fully understand all the code), then :
imho any team member who does not internally document his or her code with appropriate comments that ... at the very least ... explain their own strategies, and implementations, to themselves in a way that would easily let them explain their choices to other team members ... and also renders the code maintainable in the future ... is worthy of a career change to a position like "marketing manager," or "coffee gofer" :)
So, I would interpret the scenario which, to me, is implied in your questions, as reflecting a dysfunctional programming team, and dysfunctional team management. Something requiring : not a "band-aid," or a course in interpersonal communication, but a "cure" based on changing the "culture" of the group, and its work practices.
This is a trick question. You should never start writing a program without at least a minimum functional specification. You don't have to explain how the program works, it merely does what it is described to do in the spec. Writing a spec after you wrote the program is the wrong way around and leads to the kind of problems you are quoting.
When I interview developers for positions on my team I often pick a random project off their resume and ask "I see you worked on project Fizzbin in 2006. My mother is a retired nurse who nows runs a bed and breakfast. Suppose you were staying at her B&B and she asked you what project Fizzbin was about."
I'll then often ask them to give me the "elevator pitch" -- you find yourself alone in an elevator for 60 seconds with your CEO, who says "so, tell me about project Fizzbin" and you wish to convince them to continue your funding.
And then I'll ask questions that dive into the technical aspects.
What I'm getting at here is that I like to see candidates who can talk about the purpose of the code in terms ordinary people can understand, who understand the business reasons that the code is being produced, and who have deep technical knowledge and can communicate that.
No kidding, I have had candidates "tell my mother" something like "well, with project Fizzbin we took advantage of the homoiconicity of Lisp to build a layer that could apply maps or reductions in query objects to a geographically distributed data set across a multi-tiered blah blah blah blah blah blah blah", completely inappropriate for a conversation over breakfast with my mother.
Many candiates are completely unable to tailor their communication style to the audience appropriately. The best way to explain a program is to know what aspects of the program the person you're explaining it to is interested in, and concentrate on those, while leaving out extraneous details that they're not interested in.