One point that I'd like to make is that the use of modules can enable you to leverage the work of an expert in some topic that you don't need to take the time to become an expert in. For example, just because you could learn everything there is to know about implementing a database interface doesn't mean that you necessarily would want to spend years learning all the ins and outs so that you could write your own DBI. In the meantime, you would be missing out on a lot of opportunities to actually "get something done." And then when you do finish your home-brewed version of DBI, your next client will ask if you could handle an XML stream, and might have no use for your shiny new database interface.

Then there's the point of testing. And not just unit tests, but the tests-bed of thousands of real-world users. Look at DBI again. It would be one thing if a single author wrote it, and then he was the only one to use it. Hopefully he developed thorough tests along the way. But the reality is that thousands of people use it, and are able to find and report issues that the original author may never have considered when writing a test suite. The module has become mature, trusted, tested, used. It has years of embodied work in it that have brought it to the level of quality we enjoy today. There may still be imperfections, but its current condition is years ahead of any database interface you might cook up in a week or two.

Do you have years to invest in every niche that you may run across when developing solutions?