I have also tried to organize a programming course, on small scale (my son and some classmates want to go to an IT class in secondary school). I have to admit that I planned more, but I think having most of the attention of some 14 years kids for like ten occasions (and between them when "working for me") is not that bad. So, you might find something usable in what I tried to show them.
I talked to them about programming in general: the basic concepts of separate components, responsibilities, communication. I used the analogy of some crabby dwarfs: all software are build from them, they want to know one and only one thing, but do it well. They are happy if they don't have to talk too much, and don't want to be instructed in details: clear orders, clear responses, no intrusion into their worlds. (OOP at its best, without the magic words). I also talked about the computers and the "world" existing in the running programs, but this was not that important.
And here is the trick: after explaining the dwarfs, I immediately asked them to choose a task, solve it by creating the proper dwarfs: imagine them, explain what they know and what they do for the others (added some hints like separate the "display dwarfs" from the "workers"). The result was quite good: like a properly segmented stopper / timer / clock, and a text-to-speech app design. We then discussed the structures, analyzed and corrected the mistakes together.
Then I asked them to find a task that is interesting to them enough to work hard with it together and for a long time as a team, because this will be tough. They have chosen the poker game. We totally skipped the display part, started with the workers (card, player, location, round, game, ...) and their communication. I forced them to create sharp statements this time, nouns are data, verbs are services, each noun and verb must have its detailed explanation somewhere inside a dwarf. They did not like it too much, but worked well under pressure. The game finally got its shape, we talked a lot about data structures, single and collection instances, constant and mutable information, "where" to store pieces of information and why there, when instructing others, what to send with the order, and what should be there at the executor side (core OOP again). We eventually touched the problems of caching as well... I played with switching dwarfs between the kids, to motivate team working and clear, explainable descriptions. They even started using gliffy.com to design the structure.
When the result was clear enough, I asked them to design the user interface: what to see where, how the game should look like and run. We could also talk a little about ergonomics here: what I want to see, what I don't, what I have place for, what I don't, how can I see the state of the game, how to show that I am not able to do something now, etc.
As you can see, I have not talked about actual coding at all (and of course they have zero previous knowledge), because I think the majority of programming is clear thinking and design, that must work fine without an IDE, and before writing anything. I also think that what they did was real programming (more than typing and running sources from a text book), they really worked hard and learned a lot from it.
In this way, I will write the first program to show how I translate the ideas into Java code, how it becomes an actual running game. So they can see a clear code (and not a "hello world" spaghetti), but they will also understand the structure of the source because they have designed it, and learn the actual tools (files, classes, services, etc.) by watching how I use them to make their ideas work.
If it continues at all, I will ask them to find new tasks - some related, to see the reusability of the dwarfs: another game (player, round, evaluation), another card game (cards, desk, etc.), and some totally different; and slowly moving to writing their own sources (but strictly keep the rule: think first). I think we will use github from the beginning, just to get used to it.
My experience is that 14 years old kids can easily understand the most important concepts of programming - but it is very hard to keep them focused on the task, each and every time I had to repeat: "the computer is stupid, will not understand an order just because you use the right word, you have to exactly define how it should execute it!" It is not easy to keep them motivated in this way, even though they have chosen a game that they like (poker was a perfect choice by complexity as well), and I always praised them for good questions and answers, and added that "bad" answers have their important part too, and analyzed them as well. We had hard moments, but all in all had a lot of fun too (I synchronized the angry dwarfs...). This is why I thought showing their game in action would be a break through: I as an experienced programmer know how very important and great what they did each time, but they of course don't see the progress, what they expect to be "a computer doing something according to what they type" (and of course it should be a real-time FPS :-) )
And please don't miss the greatest mentor, Randy Pausch...