You should not start by teaching your students how to create functions and objects. Functions and objects are programming techniques for organizing code that has grown: functions reduce code repetition, and objects clump related data structure with the operations on that data. There are few <8-line program that provide a truly useful context to justify this. According to Situated Learning Theory, your students will not be cognitively convinced about them and will not learn as well.
You might think that "context" just means "frame story", but that's limiting. A good context provides justification. This is distinct from the Usefulness aspect of the MUSIC model - that is a motivational concern, and context is a cognitive.
Take a look at the attached image. We can analyze the frame story about a grandmother according to our motivational theory:
In the context of CS Education, you need to teach functions in a situation where they are useful. Restructuring a 5 line program into 4 isn't terribly helpful. When you start looking at 20 line programs, and you can teach the students to restructure them into 4, that's helpful. That's when students should look at the technique and say, "Oh! That's why that's useful!"
The useful context for refactoring techniques like functions comes from maintenance, not development. In the former, you are approaching a new program from scratch, and in the latter you should be able to keep most of your current work in your head. Therefore, a motivating context is to give them a long program (without functions) that they've never seen before and told to fix its bugs. I would introduce a few typos in some of the repeated code blocks. I would try and make this experience painful for them - the program would be cryptic and poorly written (And I'd motivate it to them that "most code in the wild is like this", and that "your first programming job will be maintenance, not development"). Then I'd let them repeat the exercise on a program with functions - this experience would be much nicer. The followup lecture would have them compare the experiences. Ideally, then they would see the value in using functions.
Two big takeaways:
Dr. Phil Conrad responded on Facebook about my blog post. At some point, I want to rewrite it taking his criticism into account - I have indeed unfairly misjudged functions, in my haste. He writes:
I totally agree with you about objects. I could not disagree with you more about functions. Functions are the fundamental unit of computing---NOT assignment statments, NOT input/output statements. A function that takes parameters and returns a result is ABSOLUTELY the fundamental unit of CS just as a "cell" is the fundamental unit of biology, and atoms and molecules are the fundamental units of Chemistry. The statement "Functions and objects are programming techniques for organizing code that has grown" reflects a bias about how CS has traditionally been taught, where functions show up in Chapter 5 of the textbook instead of Chapter 1. If you want to teach "expressions" with hard coded values before functions, fine, and then you can show a 5 line program than be usefully reduced with a function. But the longer you delay functions, the more you are carving in stone a pathway of thinking about computing that leads to bad habits that have to be unlearned, slowly, painfully. In the extreme, you get seniors that still approach every problem as "prompt for input, compute value with assignment statements, print result", write mononlitic mains and only factor code into functions that "divisions" of the monolithic main that refer to global variables. The useful context for functions is NOT NOT NOT NOT NOT just maintenance. Totally with you on OOP---that is a technique for managing LARGE code. But functions are fundamental, and confusing the two is a dangerous misconception.