Developers should know from experience that in projects of any substantial size (pretty much anything big enough to deliver to a customer or client), there will be a need for little utility programs or libraries and classes to handle routine tasks. When those moments occur, typically what’s called for is something simple and easy to get up and running, because it’s not very much value-add to whatever it is you’re building.
Take parsing command line arguments for example. It adds very little of value to the end product, but it’s the kind of thing that winds up being necessary. It’s a cost of doing business with the computer. A developer has to decide how to handle addressing the need: start from scratch and handle command line arguments manually — writing JIT code that will very likely become hard to update later on, buy a vendor product?
Most developers are inclined to do the former. I know I am – developing is what we do! What’s one more minor thing to build in order to address needs? The problem with this approach is more systemic than just the downside up ending up with old, crufty code that wasn’t designed well enough to be maintainable later on. Every developer winds up with their own hand-rolled mini-library for handling the mundane – sometimes more than one! That represents a lot of duplicated effort and inferior quality.
Of course, what I’ve just done is summarize a large portion of the motivation for open-source software . More specifically though, I recently discovered TestApi. It’s just quietly hanging out there on codeplex (written by Microsoft devs on the clock), but it addresses a handful of these mundane infrastructure things that gets in the way of us building software with real value.
I just wish I had known about it a long time ago.