Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I don't know UDK,but I'm interested is it possible create war shooter(like Call of Duty,Medal of honor etc.) with Udk in one year with two programmers and one 3D designer?I'm not say as good as Call of Duty or Medal but close to them.
As someone working in the games industry, I would say no. There is a good reason for multiple year development cycles with those teams. Call of Duty games take 2 years to develop even with large teams like Treyarch (around 250 employees).
It's not simply creating tons and tons of content, but making it all fit together, and all the dependencies between things going in. Like you can't start scripting up encounters until you have a level blocked out, and you can't start adding effects to weapons if the weapon isn't in game. You can't localize the text or dialog until it's finalized. A lot of that also depends on new tech from the engineering team. Etc etc etc.
That's all independent of what engine you choose to use.
Yes.
It is an extremely ambitious goal but if you are all working full time on this you could get something of middling quality in that time. It may be buggy and/or unoriginal but it could be done.
No chance of it being anywhere near the quality of the mentioned games though.
Umm of course you can do it, 3 ppl army to build a whole game, well... I will suggest you one thing, scrap cinematics, get rid off nonsense levels and cut to the cheese, thats whats most of the hard gamers look for, no fancy cinematics, straight to the action point.
In my opinion a good multiplayer game mode will do the trick as ,,, per now.. and wait fot the feedback, maybe if your game is good enough you can hire more staff, and work on the 1 player side. So cut to the cheese, and straight to the action, thats my opinion according to the amount of ppl involved in your game development. And many guys here will tell you,, ohh noo you cant get the same level of quality as COD, gee man of course you cant, thats obvious,,3 against 100's no chance, but what it is important is the idea, you have a good idea, put it on paper and then on your game. Dont go crazy and try to create the whole thing, theres no physical time for you 3 guys working 24/7 to finish this off in a year. So, start little with good visual texturing, then go from there. I hope you guys do well.
Nowadays that might be almost impossible. I work at Treyarch, and while I can't say much details, here are the basics:
You need QA - just this, and your quest is over. And this is only to test your game play, logic, whether a level can be completed, etc.
You need even more QA, for things you've never expected - certification (Xbox, PS3, Nintendo), localization (language, censorship, etc)
You need production team. Very motivated and goal oriented.
You need programmers, artists, animators, builders, scripters.
You put at least one person behind every profession, and you need at minimum 10 people. That would've been fine 15 years ago. Unfortunately not now.
People can still do it. There's been some game development of 9 people of sci-fi robots game using UDK (can't remember the name of the game) - but this means engine is provided, and the people have very good motivation, and probably are very good themselves.
Of course you can...the art assets won't be as good though
If you were to purchase your assets (3D models, open source engine, pre-made textures) then I suspect this could be all put together if you guys coded in only the fundamental parts of the game that make it yours.
The question is how much do you want to have commercialy bought versus homegrown and implemented
I came to a career in software development with a degree in English, rather than Computer Science or another science/engineering background. I have gone a long way on my self-taught basis, but after 10+ years of doing this, I want to go back and fill in the gaps, particularly with the math.
The obvious place to give myself a Comp-Sci education is to go through The Art of Computer Programming. However, as I didn't take all that much math and my last math class in college was in 1995, I need some brushing up and augmenting to even be able to read the math notation in TAOCP.
My thought was to go to Khan Academy and work through the necessary topics as a remedial prereq to reading TAOCP. However, in a Catch 22, I'm trying to figure out which topics do I actually need to go through as prep.
So, what I'm wondering is, if someone basically only had high school math (I've got a bit more than that, but I think it's a valid question for someone to approach this with just high school as a background), what math "classes" does one need from somewhere like Khan Academy in order to start TAOCP prepared to read and understand the included math?
Knuth is not the place to start. It's the place to strive for.
So, remedial math is good. But don't beat yourself up if it takes years to master the math required to read (and understand Knuth).
Old, but still excellent: http://www.amazon.com/Fundamental-Structures-Computer-Science-William/dp/0201087251
Look for titles like this:
http://www.amazon.com/Discrete-Mathematics-Computer-Science-Curriculum/dp/1930190867
Or like this
http://books.google.com/books?id=b9nHPJvP7xgC&printsec=frontcover&dq=computer+science+mathematics&source=gbs_similarbooks_s&cad=1#v=onepage&q&f=false
You want "discrete mathematics" to start with.
Also, you'll eventually need
http://www.amazon.com/Computability-Computable-Functions-Foundations-Mathematics/dp/0534103561
Or something similar.
A very easy to understand book is Discrete Math with Applications by Susanna Epp. Excellent book, great application and interesting. Buy it used. It should provide a good foundation.
Echoing the others, a discrete mathematics class is what to aim for. One of the strengths of Knuth's books is the extensive algorithm analysis in the text and in the exercises. A undergraduate sequence in calculus will be needed to understand some of the analysis. And "Seminumerical Algorithms" would be best appreciated I think with a undergraduate number theory course. Plus number theory is fun in its own right!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Original Question
I was invited to the kindergarten group of my elder daughter to talk and answer the kids' questions about my profession. There are 26 kids of age 4-6 in the group, plus 3 teachers who are fairly scared of anything related to programming and IT themselves, but bold enough to learn new tricks. I would have about 20-30 minutes, without projector or anything. They have an old computer though, which by its look may be a 486, and I am not even sure if it's functioning (Update: it isn't).
My research turned up excellent earlier threads, with lots of good tips:
How would you explain your job to a 5-year old?
Career Day: how do I make “computer programmer” sound cool to 8 year olds?
What things can I teach a group of children about programming in one day?
My situation is different from each of the above though: the latter ones are concerned with older children, while the first one is about talking to a single kid (or elder person) — a group of 20 is a whole different challenge.
How can I teach the kids and their teachers about programming in a fun way?
Plan Based on Answers
Thanks for all the amazing answers, guys :-) I don't think it makes sense to accept a single answer, but I like Jim's the most, just as the majority of SOers apparently do. However, a lot of other answers contain useful hints and ideas (some of which I will surely use on future Career days in the school...).
I put together a rough plan:
Briefly explain what programming is, like in this answer.
Tell that computers are everywhere, and collect examples with the kids (as suggested in several answers below).
Do Jim's presentation with the sandwiches.
If time allows, build it further:
explain that the strength of computers is that they remember exactly what they are once taught (and demonstrate it by preparing a second sandwich, repeating all the faults of the first attempt)
have a second round trying to fix the bugs in the process
explain the concept of loops: you can make the computer prepare n sandwiches with a single instruction
This is my plan - I am pretty sure it will turn out very differently, so I will improvise according to the situation. The presentation is scheduled in about 2 weeks time - I will update the post afterwards and tell how it actually went...
Results
Finally the day of the presentation arrived today... in brief, all went fine and it was a huge success :-)
The group turned out to be quite restless and energetic this time, so the conversation occasionally went a bit chaotic. I had to cut it short and get to the Big Sandwich Maker Show. Just as Jim described, the kids loved it.
There was one unforeseen side effect though: after the first slice of bread finally got ready, everyone wanted to eat! So for a while - during which I tried to keep up the conversation and explain more about programming - we had to install a sort of emergency service line with the kindergarten teachers to produce immense amounts of marmalade bread and feed the hungry crowd (this was half an hour after breakfast, for the record :-). Then we ran out of bread, which clearly meant the end of the presentation. The biggest burst of laugh erupted when after cleaning up the mess, the kids noticed that the poor computer stepped on a patch of marmalade which ruined his sock :-)
The teachers themselves were also very positively impressed - judging from the feedback, this was the best and funniest Career day in this group so far. Thanks again to all of you for the great ideas!
Things that could be improved (next time):
When I asked "do you think computers are smart?", to my surprise most of them answered "no". I then asked who thinks computers are smart, and why. However I neglected to ask who thinks computers are dumb, and why - thus I think I missed some potentially intriguing answers.
Inviting the kids to come around the table got them actively involved... but maybe a bit too actively at times. Bread slices started to disappear from the table and some of the audience mimicked the computer as closely as dipping their own fingers into the butter and the marmalade :-) So it is better to keep some distance.
To keep the hungry crowd under control, the kids should be clearly told in advance: "you can eat all the bread, but only after the demonstration!"
But overall, I am quite happy with the outcome. And I am sure the kids got the core message: as a programmer, if you avoid creating a mess, you can make your bread (even with marmalade :-)
I've done this before.
I laid down a lot of paper towels on a table, and got out a loaf of (cheap) bread, a small tub of butter, a small jar of jelly, and a plastic butter knife.
I said to the kids, "How many of you think computers are smart?" Most of them raised their hands. I said, "Computers are really dumb. People are smart. You have to tell a computer everything. It doesn't know how to do anything. I'm going to show you what I mean. I'm going to pretend I'm as dumb as a computer, and you guys tell me how to make a sandwich."
And when the first kid said "open the bag of bread!" I ripped the bag apart and let bread fall randomly all over the table. That got a lot of giggles. I continued to take the kids literally at their words until they learned to give short, specific commands, and eventually we ended up with a butter and jelly sandwich. There was a lot of laughter but they came away understanding, at least a little, what a programmer does for a living.
(I should note, I've also done this demonstration with adults in an "intro to programming" class, and it works just as well with them.)
What about doing a kinesthetic version of Logo?
Say you have two kids side by side. Can they figure out how to switch places using only the commands Step Forward, Step Back, Turn Left 90 Degrees, and Turn Right 90 Degrees? I'm sure there are other games like going through a maze, etc.
I'd think you'd keep their attention if you can keep them moving. This will spark the interest. They'll figure out later that the job is sedentary. ;)
Don't try to show them anything on the computer. Watching someone else type is boring for adults. For 5-year-olds, it's a recipe for anarchy.
Instead, make it interactive. Some form of "Simon Says," but have them be the programmer.
I've never tried this, but it might be fun.
Physically demonstrate an algorithm by using some attribute of each kid as the input data.
For example, get them to form a line (in whatever order they go to initially), side by side. This might work better in a semi-circle so they can see each other doing the exercise, but there has to be a break in the line somewhere. Then, starting at one end of the line, get them to take turns doing "if the classmate on your left is taller than you, switch places; otherwise, stay put." The game ends when you go through the line and no one switches places. Get them to observe the results. (Hint: bubble sort!)
Make them write short programs for you to do simple things (like enter the room and take a seat) and then execute them literally to demonstrate the "bugs" -- where they were not specific enough or didn't take something into account, so that you will do things wrong. Try not to hurt yourself in the process. It should be funny and will get them a pretty good idea of what an algorithm is.
To turn the kids onto programming, you drive up to the kindergarten in your Rolls Royce and walk in with your gorgeous significant other.
If you're not Bill Gates, then you'll just have to explain that you sit in boring meetings for 4 hours a day, print cover sheets for TPS reports for 2 hours, and stare at stupid stuff written by preceding clueless programmers for the other 6 hours. (No need to mention that then you field calls from people who are maintaining your last program and who think YOU are the preceding clueless guy).
No, i'm not bitter, why do you ask?
Seriously, (I am sure I'm plagiarizing from one of those 3 threads subconsciously), have them play "give instructions to me on how to do Y", with you doing things the Genie way - all wrong unless instructions are very precise and clear. Actually mention genie as good example assuming the kids saw Aladdin.
;^)
I think you could do the following demonstration in 20 minutes. Maybe it's more suited for older children. I don't really know what kindergarteners are capable of. I'd personally avoid trying to explain programming, and instead describe a problem that we as programmers solve. For example, if there are enough children, you can demonstrate the Internet to them interactively.
Part I: How it Works
First describe to them, preferably with props, how the Internet works. Bring in a laptop connected by a cable (for visual effect) to a home router. Tell how computer programmers make all sorts of devices, including the programs on the laptop, the program in the router, and applications in other devices connected to the Internet, like cell phones.
Explain how computers aren't connected directly to each other because it's impossible to connect a cable from every computer in the world to every computer. You'd need a billion cables in your house. So instead, computers connect to routers. And routers give packets of data (for example, e-mails, pictures, or videos) to other routers until it finally gets to the other computer.
Describe the rules for a computer to talk to another:
A computer can only give a packet to its router.
A router can give a packet to the computers connected to it, or to the nearest router.
This explanation should be very short, but emphasize the rules. You should probably equate packets with e-mail or pictures.
Part II: Interactive Time
Then have 3 children volunteer to be routers. Everyone else is a computer and divide them up evenly. It'd help to have colored cards they can hold. Like the person holding the dark blue card is router that can talk to all the people holding light blue cards. Let's say you give out blue, red, and yellow cards.
Arrange the "routers" in a line, blue, then red, then yellow. The blue router will then have to give a packet to the red router to give it to the yellow router. Group the other kids around their routers.
Bring "packets" for each child. Mix it up with photos, letters, a print-out of tic-tac-toe to symbolize a game, or whatever. Start by having a single red computer send to a yellow computer.
"Ashley, pick a yellow computer that you want to send your picture to. OK, to send the picture to Brian, you have to give it to your router, Kelly. Tell Kelley who should get the picture. Kelley, you are blue, so you can't give the picture to Brian. You have to give it to Timmy. Tell Timmy who should get the picture. Timmy is red, so he can't give it to Brian. He has to give it to Renee. Renee, you can give the picture to Brian since he is a yellow computer and you are the yellow router."
Then have everyone think of one person to send their "packet" to, and watch your impromptu network in action.
Part III: Relate back to computer programming
To conclude, ask the routers whether it was easy to be a router, or hard because there was a lot of people trying to give you pictures at one time. Point out where things went wrong and tie it into real problems that we solve.
"I could see that Timmy was overloaded with packets because everyone had to send their packet through him. As computer programmers, we have to solve problems like this every day. One way we could solve it is to give Timmy 4 arms. Or maybe add another router so that if Timmy has too many packets to deliver, you could give it to a different router instead." Or "Maybe we want pictures to be delievered faster, so we could ask the router to deliver the picture first before delivering any other packets."
To kind of borrow from the other ideas already posted, a game of Simon Says may be the way to go. However, you can stress how computers will do EXACTLY what you tell them to do. So, if the kids are Simon, and they say, "Simon says sit down." then you just sit down on the floor (not in a nearby chair or anything). Follow instructions to the letter and not to the spirit. (Of course, this may be tricky getting the kids to give ambiguous instructions, but I'm sure you can come up with something.)
Other than that, you could also talk about video games or other computer "things" that the kids may have used and you can say that programmers, like yourself, create those. And then maybe jump into the Simon Says to show how it works. Of course, this could result in a bunch of kids growing up thinking that you spend your entire day at work playing Simon Says with a computer...
I sometimes regard my job as playing with Lego bricks. You start with a set of bricks of different sizes, shapes and colors, and from that you build larger things. You can build castles or star wars robots using the same set of bricks.
And, it's about the same amount of fun!
One of the major perks of programming is the ability to create things. To make dreams come true. I don’t think this will appeal very much to small children who have no problem to let their imagination roam free anyway. What do computers bring to the table?
Instead, you could probably interest them in problem-solving, puzzles. The kind of thinking that is needed for programming. I probably wouldn’t use a computer at all; instead, let them solve an engaging mathematical puzzle. It doesn’t have to be hard but it should involve creative thinking.
When I try to explain programming in a short amount of time to people who aren't familiar with programming, I explain it using Legos. With Legos you have a bunch of simple pieces, this is like the programming language. Then you can piece them together however you want and make anything that you can imagine as long as you have the correct pieces.
To adults and kid this is likely to be a very interesting analogy and it still demonstrates the concept of programming.
Also, you could even build a Lego car poorly, then also display a Lego car with very nice design, and show them that programming is just like this. You can program cars or robots or whatever you can imagine, but there's not only one way to do it, there are many ways to do it. some better than others.
I have gotten so many people to begin programming and even switch their majors with this analogy. :)
I think I'd begin by talking for 2-3 minutes about computers, and that they follow instructions about what to do.
Then I'd demonstrate with a prebuilt LEGO Mindstorms robot and program it a couple of times and run it, just to show them that it follows the program. Mindstorms programming is pretty visual and simple to grasp.
Finally I'd try to explain that there are computers running programs almost everywhere, even in traffic lights, microwave ovens and their favourite toys.
Talk about how pervasive computer programming is - it guides airlines, phones, cars, how you buy your tickets online etc.
Then teach them to write a simple program symbolically -
1.Draw a grid on the blackboard.
2.Draw cheese at one end, and a mouse at the other end.
3.Have them "program" the moues to get the cheese!
Walk them through their failed attempts as a class, maybe have the mouse fall in traps or something in the grid. They would get a thrill out of it.
How to teach kids what programming is?
Well, the first step is likely to get some cows involved!
Download a simple programming game (like IQ Marathon) onto the laptop and hook that up to a projector. While you're doing this you can talk about how being a programmer often means working with recent technology (and thereby giving a demonstration of you doing so).
Once you've got it set up (practice so you can make it work in 5 minutes or less), you can use the game to show very visually (and with cows!) how the computer only does exactly what you tell it to, and how you (the programmer) have to figure out what instructions are necessary to make it do what you want. When you get it right, everybody is so happy about your success that there are dancing cows!
From there you can answer any questions, or perhaps just let the kids try and figure out how to program cows themselves. Wherever they want to go, really.
Cows!
Give each child a cut out shape; circles, squares, triangles, different colors etc. Explain how programming is giving instructions in specific order. Hold up a picture of a smiley face and walk the kids through how to construct it. Yellow circle, black dot, black dot, arc. Then show a more complicated picture, and have the kids come up in order based on your instructions. You can even make a mistake (like putting the yellow circle over the black dots) to show how 'Bugs' creep into a program.
Demonstrate a simple lego mindstorm robot and its corresponding flow chart. You wont have to show then any code and they can see the end result of your logic by watching the lego execute your program.
Kids likes things that "do something" and flashing lights.
For my sons birthday, I made a safe (box with electric lock and lots of leds) that was connected with the PC.
They had some questions to answer, and each response resulted in flashing leds (green for good answers and red for wrong answers). If they answered enough questions right, the leds started a simple animation which ended with a loud "clonk". The safe was now open and they could collect their rewards.
It was fun to build and the kids loved it.
Sell them on the value of unattended automation. Have a kid walk to the front of the room and show the class what he does each night when he's brushing his teeth. Then have that same kid show you what he'd be doing during that time if he didn't have to brush his teeth.
Then tell that kid that you know how to move that brush across his teeth while he's doing that other thing that he'd rather be doing, and tell him he'll never even feel it. His teeth will just magically be clean next time his mother goes to inspect them.
Then maybe write some pseudocode on the chalk board that shows the Brush API accessing the Tooth resource in a background thread behind the Favorite activity.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
There are a lot of good solutions for audio and video conferencing, task, calender and document management. We got specs, uml diagrams, code generators, etc.
But still companies pour tons of cash so that people can be physically there even in the times of recession and i wonder why?
Nothing beat a face to face meeting. Period.
I work with a remote development team every day and I can only support other responders in saying that NOTHING beats working face-to-face. You need the subtle cues of body language, facial expression, and the ease of communication when you're physically present such as doodling on a whiteboard. Video conferencing is a close second but the organizational issues are difficult to overcome (meeting rooms, webcams, bandwidth...).
Communication through documentation works to some extent, but is often perceived as unnecessary overhead by developers who drank the Agile kool-aid. I try to use the phone, skype, MSN or e-mail as much as possible, but it works better with those people of the team that I've actually worked with in-person for at least a few days.
Distance isn't to much the problem, to be honest. You're either co-located or you're not.
We use a combination of Skype IM, Skype Voice, mobile phones and email to keep in touch. We haven't really got into webcams properly, but even then, there's something about face to face contact you can't really replicate with technology.
I think most companies see splitting up their workforce as a step-change. A company that started out with homeworkers is better able to find and establish an office to move them into than the other way round. Money is only one consideration - it really does change the way the team works, and if you get it wrong, you don't have a team, you have a bunch of solo developers who actually take longer to do things.
Of course, it's also easier to recruit and mentor new members of the team if there's an office for everyone to work in.
Many people do better face-to-face. Many people do just as well at a distance. However, people in management tend to more focused on interpersonal relations, which generally means they're face-to-face people. So, as a general rule, people in management tend to dislike or distrust meeting at a distance.
Furthermore, meetings are very often unproductive. This applies to meetings at a distance and face-to-face meetings. Indeed, it's significantly easier to get off-topic, unprofessional, and unproductive when meeting face to face. However, when an at-a-distance meeting is unproductive, it's almost always seen as such because it was at a distance. It can be exceptionally frustrating to deal with the technology and limitations of remote meetings, and it's infinitely easier to blame the situation and the technology for your lack of productivity.
To sum up: people are a problem.
I have a few cynical and contrary opinions on this, based on my experience working for a large Australian organisation with branches all over the country and my current remote work for a US company.
Cynically - face to face works so you can do deals off the record. This may not be as corrupt or as underhand as it sounds but an astounding amount of management-level decision making happens where people negotiate relative tradeoffs involving influence, favors accrued and owed and stuff which is hard or embarrassing to quantify. Even when an organisation has a commitment to using teleconferencing, groups emerge who negotiate off-camera and thus acquire a competitive advantage.
At the purely technical level, I think face-to-face is nowhere near as important as cited. The political issue is in drawing this distinction - if you label your stuff as non-political and safe to do via remote comms, you are explicitly labeling the other negotiations as somehow not safe. Another aspect is that people looking to move up to management need to become visible and a known player in the face-to-face discussions.
Developers, including myself, are notoriously poor at picking up the non-verbal cues cited above (just ask my wife!). In a relaxed atmosphere of trust, they can use emoticons and in-jokes explicitly in IM sessions without worrying about translating someone else's expression, especially across cultures.
IM sessions, with the ability to search the transcript, are far more efficient than verbal or video conversations, when discussing projects. If you don't pick up some nuance at the time someone says it, you can go back and examine the exact sentence in context.
I use video chat infrequently and the main use of voice chat is so I can talk to my boss in his spare time whilst he's driving. Those are good conversations to give me a general feel for how things are going but usually inadequate for technical.
Here's a podcast that talks about distributed software development: Managing Commercial Software Projects. Here's a blurb from the show page:
Andy Singleton is an entrepreneur who
has long studied and practiced the art
of distributed software development.
Influenced by the open source and
agile movements, he has arrived at
some startling conclusions about how
to manage commercial projects. Among
them: don't interview people, don't
estimate schedules, and don't spend
time in teleconferences. In this
conversation with host Jon Udell he
explains why not to do these things,
and what to do instead.
I thought it was pretty interesting.
Face to face meetings provide a lot of visual feedbacks which you do not get in other means. This is must if you want to discuss important subjects like architecture, reviews etc, which tend to be slow or useless if done over phone, email, twiki etc.
Typically status updates can be done via other means, we normally use Skype, Twiki, Email, Phone keep in sync.
I really like communication via IM, email or phone. It's totally ok and I really appreciate using it.
Now comes the big "but" (with a single 't'):
You are not able to "just walk over" your colleague and ask him** a short question. For sure, you can IM him or mail him. But it will take some times till he answers your question.
The other point is drinking coffee. You cannot just drink a cup of coffee with him and talk about your problems.
If you let your brain release your thoughts, problem will disappear. And that's one reason behind drinking coffee with colleagues.
I really need personal communication. I need it. About 70% of the communication can be replaced by IM or whatever, but the 30% are very important.
** him = him/her
Some 80% communication is non-verbal, video conferencing helps a bit, but is not good enough.
There have been studies done over success rate of business negotiation and project cooperation depending on type of communication used. It was ranging from 90% success face to face, to less then 10% with email and text only IM.
For example one of such studies, conducted by Harvard Business School professor Kathleen L. Valley yielded for example such results:
"among 24 four-person decision making
groups interacting via computer, there
were 102 instances of rude or
impulsive behavior. Another 24 groups
that interacted in person yielded only
12 remarks of that nature."
Related Wired article: "The Secret Cause of Flame Wars"
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Here is what the Wikipedia article on Scrum has to say about the Daily Scrum:
The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck).
Do you feel that it is a good practice and what self-punishment have you found effective in the past?
When I've been the scrum master we always started on time regardless of whether everyone is there or not. If people don't make it they miss out - no chance to engage with the rest of the team on their progress and blockers. In my experience, it only takes one or two times for that to happen and the team self polices - people know we start on time, finish on time, and if you're not there you miss out - no punishment needed, it's all done by peer pressure.
BTW set your scrum time the same time every day, and allow for people's work patterns ie - 9:00AM doesn't work for everyone, but 10:00 should do, even better go for 9:50, run for 10 minutes and you don't crash anyone elses meetings.
I think it's bad practice. My current employer schedules our weekly catchup (No daily meetings sadly) at 9am on Monday morning and hits the roof when people are not on time. Rather then getting irate and verbally punishing people, it makes more sense to me to just schedule the meetings at a time where it's more likely that people won't be late. Such as 20-30mins after regular starting hours, so people have a chance to get in, compose themselves after commuting in, maybe grab a cup of coffee and maybe check their emails.
[MrTelly's answer is the most sensible, but let me add to it a bit]
I haven't heard the word "tardy" since kindergarten!
Perhaps everyone who arrives on time should receive a gold star sticker, and anyone who is late doesn't get one. A poster board with everyone's gold stars can be displayed in the lobby so that visitors can easily see who the Good Little Children are.
Seriously, the notion of punishment in a professional environment is ludicrous. People who are late miss out on part of the meeting. If that causes their performance to drop or impacts the project, they get reprimanded for that, and eventually fired if the problem isn't corrected.
If you treat your developers like children, don't be surprised if they act like children. And vice-versa.
It's like a glimpse into the breakdown of a methodology.
Score 1, Rambo
The concept of "punishing" people is ridiculous in my book. If you have people that can't perform the tasks they are being paid to perform, I think you take them aside and find out what's holding them up. Is it the work environment, personal problems, or other? Most of the time there should be some changes that can be made or coaching given that can save somebody from becoming unemployed. If the situation can't be resolved, then terminate the person in a professional manner. But to publicly ridicule somebody, yell at them like children, or force them to pay money for their mistakes? That does nothing to build people up and will probably open you up to lawsuits.
I dislike it in general. When your late to work you boss should punish you not your peers. This is just a really bad idea.
Of course, it is to prove a point in the beginning, but if you have to do it more than once, or think long and hard on the punishment, you have the wrong people on your team.
Any work environment where 'punishment' of employees is a valid concept can take a hike.
Oddly, though, the monetary penalty is fine by me. Apparently, in my mind, that's not a punishment, it's a fine. I cost other people productivity, theoretically, so I'm okay with that costing me some money. The others are fundamentally humiliation-based, which is not wise.
No one likes these "punishments", but the reality is that the meeting could be at 2pm and people would still be late. Every office I've worked in has had problems with people (and not always the same people) showing up 5 minutes after the meeting has already started. Sometimes it's because they hit Snooze for "5 minutes" at 5 minutes before the hour. Some people just aren't considerate enough to show up on time, and it doesn't matter how you punish them. Sometimes it's because their last meeting ran up until the very end of the hour. (I try to wrap my own meetings up 5 minutes before the hour, for my own benefit.)
But, having said all that, we put $.50 into a jar for each occurrence and at the end of the iteration someone would walk up to the bakery and buy a pie (typically $5-6) to celebrate the end of the iteration. So, it was punishment, but at the same time it got us some dessert too. ;)
We've got a fun practice that keeps the mood light (for tardiness or any other "offences") but still gets the message through.
If anyone is late to the meeting (which we will invariably start without them) they get a "fine". Fines are recorded and when a person has accumulated 4 fines they have to bring lunch for the team.
We issue fines for other things like your phone ringing (not on silent) during a meeting etc.
It works well to keep the energy up, brings us together as a team, we laugh about it, but the message is clear that some things are unacceptable.
The point of these punishments is to make people realize that being at the meeting is important. While scheduling at a time people are likely to be able to make it makes sense, the truth is that some people will always be late if they are allowed to be. Either they have poor time management skills (not uncommon in developers) or they think the meetings are a waste of time and are rebelling in a not-so-subtle way. Either way they are hurting not just themselves but the rest of the team, and there needs to be some way of impressing that on them.
However most developers also resent punishments imposed from above. What I would suggest is having your team, not you (as scrum-master) decide an appropriate punishment. Then the reluctant attender is responsible to their peers, not under the thumb of authority. In my experience the 'punishments' that work best are those that are irritating enough to be avoided but not difficult or humiliating; maybe fetching a cup of coffee for each other member of the team; monitoring the daily builds for the next day; buying donuts.