The book shows you the programming techniques for modules and procedures in VB.NET, but it doesn't really get into the larger question about when and why to use them. This subject is usually called analysis and design. You will usually use modules and procedures because you have a programming problem that requires analysis and design, so this is the right time to study the subject.
It's discouraging to realize how often programmers don't even have a design. They have an idea and then they just start coding. After the system gets so complex and complicated that they just can't deal with it anymore (oh, and by the way, the project is now way over budget and schedule), they will be heard to mutter, "Maybe I should have designed this thing first." Yeah, right, Einstein! Now is a great time to think of it!
Sorry for being so ... well ... 'assertive' about this, but I have been involved in too many software rescue situations to take this calmly anymore.
Deciding the "right way" to understand your system development problem and how to divide it up into different programming modules is a problem so difficult that software designers have never agreed about it. And they still don't. But from the point of view of someone just learning to program, it's enough to realize that it's an absolutely essential part of any project that goes beyond just a trivial example. When you do tackle a more difficult project, remember to do at least some design of what you're going to program first.
