You have in-house interest and skills to create your own software application. Why not take advantage of this less expensive option? Learn from others’ experiences with DIY applications before you decide.
When my mother looked at the prices of new hats, studied their features, and then went home and tried to remodel her old hat with feathers or lace to look like those fancier models, I saw the effects of her value for doing things herself—attitudes perhaps shaped by her own parents and their experience with Depression-era shortages. Even earlier, Michel Guillaume Jean de Crèvecœur, a French visitor to eighteenth-century United States, commented on Americans’ resourcefulness, doing things for themselves rather than relying on others. “From his own resources, the farmer fashions new shoes for his children,” Crèvecœur marveled.
While this kind of resourcefulness and independence may be an admirable trait in individuals, it can often hinder organizations from moving ahead, costing far more in the long term than what it may save in the short term. This is especially true of software development.
Organizations with computer programmers galore often decide that their own application needs can be met by depending on the skills of these programmers, rather than by purchasing from a firm that specializes in management software.
PQ Systems itself, it must be acknowledged, went the Bob-the-Builder route, with a “We can do it” approach to building a customer database in the 1980s. One of our company’s crack programmers did indeed write a program that met our needs and had some whammer-jammer features besides. Problem solved: money saved, our resourcefulness demonstrated nicely.
But not so fast. When that programmer left the company, no one else really understood the way the program could be maintained and updated. We were stuck for several years with a clumsy, clunky, unfriendly application that required hours of figuring out ways to improve it, or of wringing our hands in exasperation.
Some of our customers have done the same thing with both gage maintenance and SPC solutions. “We can make our own charts from Excel,” they say. Surely making simple charts from data can be accomplished without the application of rocket science. But with 21st century software—as in the case of consumer products—we have come to expect more than simply a way to do something. We want more than being able to create documents in a word processor; we want our word processing software to help us spell, create new formatting, change fonts, export to other programs, and accomplish a myriad of other tasks that were undoubtedly never envisioned by those who first created word processing software. We would never consider creating our own word processing software, when excellent programs are not only available, but are also being upgraded and improved constantly. If we want our application to provide alerts, offer real-time data, and provide a variety of ways to look at that data, we clearly want a far more agile product with ongoing improvements and added functionality.
A frequently-overlooked aspect of software development is that of maintenance—something that demands both time and money in addition to expertise. A foundational study in software maintenance that is widely referred to is that done by a team at UCLA led by Benet P. Lientz and E. Burton Swanson in the late 1970s (http://agile.dzone.com/news/lientz-and-swanson-software). Their research has largely held up even after so many years, and demonstrates that around 60 percent of maintenance costs were spent in enhancements, better documentation and more efficient coding – what Lientz and Swanson called “perfective maintenance.”
The fact is, the process of fixing defects and providing ongoing maintenance demands continuous attention from someone—the lone programmer who created the program, the outsourced group that wrote the code, or a firm that focuses only on developing and maintaining that program and is willing to answer questions and respond to suggestions from users. And of course, this is true for Version 1 of the product. Who will be thinking about Version 2? It’s clear that the “true cost” goes far beyond original development expenses. http://thebiggh.com/2012/08/20/the-true-cost-of-developing-software/
Lest we protest too much, our own bias as a software development organization must be acknowledged. While we see the advantages of a low-cost, good-enough product that can do certain tasks reasonably well, we also have the perspective of our own experience with DIY software, and the knowledge that our full software development team does nothing except develop and maintain our software products and listen to the voices of our customers who use these products for a variety of critical tasks. It’s a full-time job.
Our advice: Save your do-it-yourself projects for the weekend. You can probably fix that leaky faucet yourself, and if that doesn’t work, there’s always a professional plumber who can clean it up for you.
Or you could just call that plumber in the first place and save yourself a weekend of frustration.