Notes:
The "old" process was simple – gather user requirements, design the screens, code them, test the system and fix any problems. It was not efficient.
The "new" process looks like a lot more work – which is why a lot of organisations prefer the "old" approach. And if it is done without understanding what developers need to get the job done it can turn into a lot of pointless paperwork.
In practice developers joining the project were enthusiastic about the documentation they were provided and about participating in a review of this documentation before starting work.
They found it harder to come to terms with designing classes without simultaneously implementing them. But they were usually convinced by the issues that were caught when reviewing them.
It was much harder to convince them that it was worth taking the time to write test harnesses – but they soon noticed that they were no longer spending 90% of their time wading through "old" code fixing problems.
The next section will discuss how do we do these things right, but it was very important to demonstrate results.