Software development is a learning process...
The first four paragraphs from the first chapter of one of the best books available about Test Driven Development, Growing Object-Oriented Software, guided by tests.
[caption id="attachment_227" align="alignright" width="225"] The first page of the first chapter of the GOOS book.[/caption]
Software Development as a Learning Process Almost all software projects are attempting something that nobody has done before (or at least that nobody in the organisation has done before). That something may refer to the people involved, the application domain, the technology being used, or (most likely) a combination of these. In spite of the best efforts of our discipline, all but the most routine projects have elements of surprise. Interesting projects - those likely to provide the most benefit - usually have a lot of surprises. Developers often don't completely understand the technologies they're using. They have to learn how the components work whilst completing the project. Even if they have a good understanding of the technologies, new applications can force them into unfamiliar corners. A system that combines many significant components (which means most of what a professional programmer works on) will be too complex for any individual to understand all of its possibilities. For customers and end user, the experience is worse. The process of building a system forces them to look at their organisation more closely than they have before. They're often left to negotiate and codify processes that, until now, have been based on convention and experience. Everyone involved in a software project has to learn as it progresses. For the project to succeed, the people involved have to work together just to understand what they're supposed to achieve, and to identify and resolve misunderstandings along the way. They all know there will be changes, they just don't know what changes. They need a process that will help them cope with uncertainty as their experience grows - to anticipate unanticipated changes.The rest of the book goes on to explain how to do TDD properly, and how to use it as a design technique to help us build software when we don't understand what it is we're creating. This process of creating something out of nothing, making it do something we didn't know we wanted it to when we started, allowing it to develop new skills over time and using the stuff we use to make it in different ways from how we've used it before; this programming lark. It's not easy.