Design-before-you-code is a school of thought that believes that what code is to be done (or what classes to be made and how they will interact) should be thought of and documented, reviewed looking at alternatives and also checking for the necessary and sufficient condition of fulfilling the need with probable extensibility in case of changes.
So if we see, any one who is not doing "design" before coding, must also be having these thoughts in mind while firing up the code editor and writing the classes and its methods. If someone is thinking about the classes and its interaction, it is better to follow the design discipline.
But with programming styles like agile, peer programming etc, the need for exclusive designing is decreasing in certain projects. However the product development teams that work on hardcore engineering products do follow the design discipline. The benefit is not only reduced coding time, but also maintenance of the product in long run.
People at times come up with question that "Can there be real examples citing this?". I don't know exactly how a real example be cited. But, I have experienced both the two cases. Both in two product developments. The first one was developed without the designs being made. And we saw a lot of pain during maintenance as extensibility was a big issue. The second one was following the disciplines and we felt the maintenance was quite less painful, so lot of efforts were saved.
I am yet to experiece agile or extreme programming or TDD kind of stuff and probably have not heard anyone following these for engineering product development. I shall keep my option open to experience the same.