> But as a goal, that's really what you want: we want to solve the problem by saying "this is the solution" and then poof the solution appears! Actually, that

> But as a goal, that's really what you want: we want to solve the problem by saying "this is the solution" and then poof the solution appears! Actually, that is very often not the case. Many SW projects start with an idea of what the software should do, but there is no easy way to describe it in full detail. Writing down the complete specification right from the start would be very hard and prone to wasted work. For example, say you want to write a messaging system. You could try to imagine the whole thing and describe it in some formal language, but this will most often produce huge pile of ideas that weren't tested and are not part of desired solution in the end. It's too much "building in the head". Instead, we should prototype. We write the simplest possible thing that roughly does what we want, and then add and remove features as convenient/needed and improve various characteristics. We handle corner cases as they appear, sometimes learn that something new has to be studied / understood first, and some parts that have been written have to be rewritten and then we do so. Writing the spec for the result may be done in the end, after the software is done and works and the ideas are proven to work.