Knowing where your going before you go
Its rare that folks travel with out a map, even those in the outback have mental map of where they going (and its not like norman briggs from new york is doing the walk about, he would be croc food very quickly). So would you code before having any idea of what your doing? You must have at least have a vage idea, it needs to do XYZ but unless you know 100% what XYZ are then that means lots of room for movement on what XYZ is from your customer (could be your boss for example) and the time it took you to develop XYZ goes up and up each time XYZ changes
and up
and up
Thats a costly business but at the the other end of the scale it be costly too. In some organizations, change control is a serious busines (windows start button any one ;-)) with lots of levels of consideration of impact (big design up front approaches can glue this in). In other organizations there is non, it just happens (ad-hoc). In others the methodology can flex to the requirements.
What does this mean exactly? Well in the agile world there is a notation of iterations, the basic premise is that in a given iteration a given set of functionality is set with each user requirement (called user stories) marked on cards\paper\whiteboard\drinks mats etc. Should the customer (this could be your boss) wish to change something then that is marked on the cards for the next iteration. When the iteration is finished the next iteration begins and so on. This is different from ad-hoc in that each requirement is marked down so even though they are changing you still know what those requirements are. So how long is iteration? Often you will agree what wil be implemented in your card set so you achieve your milestone, very often you will get to the point of releasing your prodict by the end of iteration. Agile methologies do vary in gudience on setting this, very often with pair development the iteration can be very short (weeks) but lets not run before we can walk. If your boss is asking for changes every day then you set your iteration to daily and try to convince your boss to work daily. If your making releases daily or weekly then your customers customers (your boss's customers) can see the product moving and vitally you have records of what the system is suppose to be doing.
Vitally with each requirement you can create a base line of tests to meet that requirement, if the requirement changes you change the test in accordance and refactor your code to meet the test. That same test can be run by you, or another member of the team in automated and repeatable fashion.