in reply to Developing code to be a module
I have been taking both approaches.
I have been working on project where I knew that I would have to write 8 to 10 different programs and that all of them would need some common functions. So, in these cases, I wrote the module first with the functions that I needed to share, tested it, and then the programs using these modules. However, despite relatively careful planning, I still had to change the module in the course of writing the programs using them, because I figured out that some more code could be shared between programs. I can remember at least 4 projects where this happened, but there might have been more.
In other cases, it starts as a couple of function for one program et evolves towards a module. Recently, for example, I wrote my first program in a brand new system. Some of the code was needed more than once, so I made a couple of functions to avoid code duplication. A couple of weeks later, I had to make another program, and I figured out that the same functions would be needed. I copied and pasted the code of the function to deliver this second program quickly (in my opinion, a module needs careful design and should not be made in emergency) and decided that I would take the time to write a module to encapsulate the repeated code for next time. Since then, I have written half a dozen other programs using that module and I have some more to do in the next days. I am quite happy of the fact that I did not have to change the module so far, because I designed in a sufficiently generic way as to work in all cases so far. It would not have been the case if I had settle to write it earlier, before I knew enough about the type of things I would need to do on this new system.
I think that both approaches have pros and cons.