First you want some software. You know what you want, so it makes sense that it’s most convenient if the the software is built by yourself.
Unfortunately (or luckily) you’re too busy doing your own stuff to write a software. You call up someone and ask him to write the software for you. You save time and he got a job. Win-Win!
But wait. He needs to understand what you want. You need to tell the developer what you want. You need communication. One of the problems of communication is you cannot tell if you successfully communicated. You ask something. The only way to see if your request is communicated right is to see the resulting product. The developer show the product as a proof of the communication.
Time is money. If it proves wrong after several months, ah-oh. It’s wasted time. You don’t want to waste time or money. You want to see the proof early, as early as possible. So the developer wants to, for the sake of a satisfied customer, create only a small chunk of software and show it to you as soon as possible. You communicate only a small part of what you want. It also saves time because it takes time to list up all the things you might want.
Now you have a continuous cycle rather than one time order. You communicate small requirement, the developer build small software, you validate it’s what you want, you might change your requirement a bit, then repeat. Recurring communication between two people makes the communication more straight, unambiguous, effective. You get better by practice. Creating cycle in your work is the way to get better, make improvements.
By the way, you say you know what you want. Are you sure? Really? Try to tell me what you want for dinner one year later. Or a week. You can’t be sure. You want option. You want a right to change what you say. You want to change or take back what you order after the order is complete. What a bad customer! But you want because you’re not sure what you want.
Let’s make a compromise. You can ask the developer only for a week’s effort. He finishes the increment in a week and you validate the small working software. By seeing it, you learn stuff. You learn that certain things are right as you imagined, some things you misunderstood, quite a few items you overlooked. Of course you and developer also learn from their own one week’s working. You are wiser a week. You make better decision than you could a week ago. Learning is the key. Because you are human.