To plan or not to plan that is the question
As you suggest, it is a subtle question. Twenty-five years ago, the answer was simple: Plan. But too many software projects crashed and burned because of over-planning and sticking to the plan after it was obvious to all that it was the wrong plan. More recently, the initial failure of the signup system for the Affordable Care Act was likely caused by this same failure of thinking. 


Plan if you can, but be flexible enough to deviate from the plan when needed. 


That sounds like good advice, but it can, itself, be the root of too many problems. If you have a complete plan you are likely to be willing to expend resources at the beginning that will only recoup their investment if it proves to be the correct plan but will be wasted (sunk cost) if the plan proves to be incorrect. 

So, with a complete plan you can build the thing at lowest cost if the plan was correct. But you wind up with a failed project otherwise. Not only have you spent money on the incorrect plan, you have expended time and your competition may have moved ahead with a better solution. You are both late and poor. 


When you can't plan, build on a tight feedback loop. 


That is the key message of Agile development. All of the practices of, for example, Extreme Programming and Scrum flow from that message. The implication is that you don't expend resources on speculative assumptions about where the project will go. It does mean that (a) you sometimes can't take advantage of economies of scale and scheduling but (b) you don't get caught with sunk cost that you get no benefit from. In today's development environment (rapid change) this is usually a better assumption to make. 



My advice to educators is to learn everything they can about Agile Development, whether you decide to adopt it or not. The ideas are interesting in themselves and can prove transformative if not viewed too narrowly as just a set of practices. 

And, of course, read the Mythical Man Month. Its message is valid yet, though it was written for the BUFD (Big Up Front Design) era. 



Note that agility goes beyond software development. The principles of agility (see the Agile Manifesto) can be reapplied in different ways to vastly different things.