Should You Create Custom Software?
For this article, custom website software doesn’t mean the odd script emailing form results or a simple database interface. It means a relatively sophisiticated applicaiton with authentication and busienss logic requirements. So the question is: **should** you create it?
I’ve spent a lot of time thinking about custom software and whether or not it makes sense for non-technical businesses to go down that route. The answer is a very firm, “it depends” with a parenthetical, “usually, no”. Custom software is always an expensive choice. As the sole user, even though the initial cost may be roughly equivalent to buying a package and then implementing it, the ongoing costs of development and support can be prohibitive.
In software engineering (visit our custom software site for more info), we talk about the cost of change. The only thing that’s for sure about any software package is that it will need to change—probably pretty frequently. So what will that change cost? Most often the cost of change follows an exponential curve. (On an XY plot, that looks like a line that starts very low and rises sharply, like a backwards “L”.) As the product gets older, changing one small thing can require a host of other changes so that the time required to change a package is greater than the time required to recreate the package from scratch.
The goal of software engineering practice is to change that curve. Instead of rising exponentially, it can and should rise logarithmically. (On an XY plot, there’s a rise at the beginning, and then a gradual rise as time progresses.) How do we get to that shape? A lot of good ways: strongly typed languages, powerful integrated development environments, refactoring, extensive automated test suites, better practices and a whole lot more.
PHP, what a lot of web software is written in, has none of these things. Or, rather, it had none of these things back in the PHP3 and, to some extent, 4 days which is where most scripts started out. It’s getting some of them now but they’re still in their infancy and most PHP is written without them. What does that mean? That means changing PHP based programs can be expensive and error prone. Significant changes can be done, and they might be manageable, but they often become unmangeable. Many, not all, significant PHP packages stall out after a period of rapid development.
A side conversation: is PHP a valid language to work in? You bet. You can move fast and get a lot done. And you can build very focused, powerful applications in it. It’s not good for large, complex applications. Java is a better choice for that. You can also use Ruby or Ruby on Rails, but those are also subjects for a different day.
What about having to customize an existing package instead of creating a new one–won’t you still face custom maintenance costs? Yes, you will face battles with customization either way. Does this make business sense for you?
It depends on your strategy. If you are primarily a marketing or remarketing organization, I’d say no, you shouldn’t write custom software or heavily customize and existing package. Use the existing packages as is; let someone else worry about the features, and just sell as many of them as you can. If the value you provide is in customizing the packages to better suit a set of unique needs, I’d say, maybe or maybe not. It depends on what value you can help people realize with the customizations and what price the market will bear and the likelihood of someone else doing a better job meeting that requirement than you. Customizations are expensive and risky. Completely custom packages are more expensive and even riskier. And sometimes these very risky things are driven by “wants” rather than demonstrated market “need”. (People will spend a lot of money for a “want” that’s often not justified by strictly business concerns, but that’s another issue.)