In the pioneering years of the PC industry, people mainly created for themselves whatever tools they needed, because there wasn’t much of an option. I’ve lost count of the number of developers who claim to have invented their own text editor. These days, we simply buy the product or editing module that best suits our style and circumstances, and accept compromises, rather than spend time building the “perfect fit”. Of course, developers still hack things that don’t work quite the way they want, such as JavaScript frameworks, but even that need diminishes over time. It now almost always makes sense to buy rather than build or, even better, rent it as a service.

The question of whether one buys or builds depends on the maturity of the technology at the time. A few years ago, for example, we at Red Gate urgently needed a new CRM to cope with rapidly-expanding business, our instincts were to buy, but inevitably we found nothing that was a great fit. Each candidate had failings and involved compromises that were hard to accept. It was argued, successfully, that the work required to adapt what we could buy would be almost comparable to the effort to build exactly what we needed, and we duly assigned a small team of in-house developers.

At the next CRM upgrade, there will be no debate. The technology has now developed. The custom built tool will be out, and in its place will come a software package, cloud-based, and free of Red Gate-infrastructure. At the same time, out also will go any other email or marketing tools that we bought or built to plug in to the CRM. In will come commodity services to replace them.

Ready-made products tend to mature from the component level to the package, ending as complete solutions like SAP ERP. It is the same with websites. Seven years ago, when I first joined the company, I assessed several ready-made platforms for Simple-Talk, including a fledgling WordPress, and DotNetNuke. It wasn’t hard, though, to argue that no readymade solution fit the bill. We contracted a developer (now author of a highly successful HTML programming book) to build the Simple-Talk we wanted. We completed the project, end-to-end, in six months, at reasonable cost, and with a few bolt-ons and bits of sticking plaster, it’s still with us. The project was, by any measure, a success and yet to do the same thing again now would be unthinkable because there are now ready-made products out there that would be much closer to what we want.

However, this commoditization of software doesn’t always crush all creativity and initiative beneath its wheels. Ingenious new solutions come to dominance even in well-established technologies such as desktop publishing. However, in the main, the new giants seem comfortingly like the old ones. For the thrill of pioneering, the developer needs to find an area of technology where there are problems, but no established solution. That beautiful hand-crafted text editor, or JavaScript framework, that you’re secretly creating may yet emerge as the new standard, but I wouldn’t bet on it.