I ran across a twitter comment about custom software development undergoing some sort of resurgence, which linked to this rather pedestrian article on the topic which I think misses the point a bit. I have no factual quibbles with the article as far as it goes. But the tradeoffs in custom software today are not strictly “buy or build” because in virtually all cases no one “builds” 100% anymore.
Today people are finally waking up to the tremendous leverage provided by development frameworks (Ruby on Rails, ASP.NET MVC, Django and so forth) — as well as traditional libraries, which are ever simpler to plug into projects and manage, thanks to the advent of package managers. I am finally seeing fewer religious wars over languages and more over frameworks and perhaps IDEs.
But it goes still further. Cloud service APIs as well as app containers like Docker also contribute to faster bootstrapping of new “custom” solutions.
The truth is that “custom” software is increasingly crafted from lego blocks that are already finished. When I started in this business I was writing low-level keyboard input routines to get just the effects and control that I needed in a desktop app of that era; and I recall writing my own assembly language printer driver at one point, too. This kind of low-level bit-twiddling would never even occur to custom software developers today. Nor should it have to. The craft has matured.
Even the tools for automating tasks at the system level are far more capable and robust.
In the old days a client would come to me desiring a custom accounting package for, say, their paddle boat manufacturing business (this was actually one of my clients from the 1980s). Even then I would approach it by licensing a generic accounting package and modifying it to their needs (though to properly maintain it in sync with the original software vendor’s constant improvements, I ended up using a custom code preprocessor). But today I might well use an off-the-shelf accounting package and write some workflow and glue code to modify it and seamlessly integrate it to their business processes. It is not necessarily true that purchased commercial software is “too rigid”. Maybe it is too rigid out of the box, but if designed with integration and customization in mind it can be quite flexible in the hands of a skilled coder.
For all these reasons, I encourage even small businesses to consult with someone capable concerning how customizing can benefit them and contribute to their bottom line. Perhaps a small business that doesn’t need to scale much won’t use a lot of customizing, but I can imagine that many of them can still benefit greatly from some small, judicious use of a custom software developer’s skills.