COTS and corporate consumerism.

It is truly amazing the number of companies who go on consumeristic shopping sprees buying so called “COTS packages” in hopes of instant gratification.

The marketing wordsmiths of the software industry have achieved great results in convincing folk the definition of COTS is something like:

Short for commercial off-the-shelf, an adjective that describes software or hardware products that are ready-made and available for sale to the general public. For example, Microsoft Office is a COTS product that is a packaged software solution for businesses. COTS products are designed to be implemented easily into existing systems without the need for customization.

Sounds great doesn’t it.  Here is a portion of an alternate definition which rarely makes it into the marketing brochures:

“typically requires configuration that is tailored for specific uses”

That snippet is from US Federal Acquisition Regulations for “Commercial off-the-shelf” purchases.

In other words, most of the COTS packages should at least come with a “some assembly required” label on the box.  Granted, most vendors do disclose the product will need some configuration.  But most gloss over the level of effort involved, or sell it as another feature.  And most organizations seem to assign procurement decisions to those least able to accurately estimate implementation requirements.

The most offensive of these scenarios involves developer tools and prepackaged application components for software development shops. SDKs and APIs are not even close to being a true COTS product, but numerous vendors will sell them to unsuspecting customers as “ready to use” applications.

If the organization has a team of competent software developers… then really, what is the point of purchasing a “COTS” package which requires more customization (through custom software development) than just developing the features internally?

Some vendors have sold the idea that they provide additional benefits you wouldn’t get from developing it internally.  Such as:

  • packaged documentation comes with the software.
  • vendor gets feedback from many customers and makes it better for everyone.
  • vendor specializes in supporting the product.

Those are all suspect.

  • If the product requires customization, will the vendor provide custom documentation?  If not, their pre-packaged documentation will likely be useless.  The only authoritative source of documentation for source code… is the source code.  Good coding standards, including commenting and version control statements, will provide far more value than a collection of PDFs from VendorX.
    • Can the vendor provide an IDE plug-in which integrates Class, Method, API, and Interface documentation with the rest of your language environment?
    • Can the vendor be expected to keep these up date for the development tools your team uses?
  • Increasingly,  Vendors are no longer the best or primary source of product information.  User communities increasingly evolve independently of specific vendors.  Many online user communities begin with the overall service or concept involved, and develop sub groups for specific vendor products.  As a result, it is increasingly easier to compare and contrast information for many competing products at a site which shares common interests and contexts.
  • Vendor support comes in many flavors, and not all of it equally useful (or affordable) to all customers.
    • If the customer configuration is complex, continuity of support personnel is important.  Dedicated support from a large software vendor can run $1 Million per year per named individual providing support.  Otherwise your support calls go into the general queue with no continuity.
    • Large (publicly traded) software vendors operate on a financial basis which makes it difficult for them to run large scale professional services businesses.  Most every company that tries to combine product with large scale (i.e. thousands of staff consultants) professional services eventually implodes due to the cultural and financial conflicts between the two lines of business.

Failed software implementations can drive a company into the ground.  Complex COTS packages which only serve as a component to be “integrated” into customer systems through custom programming can often be a major contributing factor to project/program failures.  The larger the failure, the less likely the organization can retain sufficient stakeholder trust to try again.

Organizations with existing capabilities for large scale internal software development should reconsider the mantra of “All COTS, all the time, everywhere.”

US corporate financial practices haven’t just indoctrinated the citizenry into consumerism.  They’ve equally indoctrinated organizations of all kind.  Before you make that next COTS purchase order, pause, and give a moments consideration to “producerism”.  The long term benefits could be startling.

By the way, this phenomenon isn’t limited to software components.  I’ve seen organizations procure “appliances” at six figure costs because they perceived it to provide an application service which would save them $1 or $2 Million in software development costs downstream.  Unfortunately, they eventually learned it would require an additional $2 to $5 Million of software development costs to modify their application portfolio to work with these appliances.  After spending (wasting) 18 months and over $1 Million, they eventually found a solution they implemented internally with very little cost (simply replaced an old/deprecated programming language API with a newer one).

Advertisements

Handling Interruptions in your iOS App.

iOS – Handling Interruptions

As we all know, iOS Apps run on mobile devices.  The users of mobile devices can be interrupted by any number of things.  Many of the interruptions come from other services and features of the devices themselves.  Incoming phone calls, text messages, notifications, alerts, etc.
As an App developer, it is a good idea to plan for handling interruptions and test the results.
One simple technique for testing uses the iPhone’s built in Clock App.  Setting the alarm clock about ~ 1 minute ahead, use app and observe behavior when alarm interrupts the app.
A well designed App should respect the interruption, be prepared to be backgrounded, and be prepared to be exited.  For a good user experience, the current application state should be saved (if applicable) so the user can eventually return to the app and resume where they left off.