Based on this informal Linkedin poll, 70% of us agree with the proposition that we could live with half the features in our applications, and that performance and reliability are more important qualities.
This is not a surprising result. We all know our apps would be healthier if they lost weight. We understand that the very best apps do exactly what users need and nothing more!
If we know leaner is better, but yet our apps are morbidly obese and getting fatter every day, there must be some opposing force — a ravenous, insatiable appetite — that keeps the feature-kitchens cooking.
The root of the problem is the pretense that our industry produces COTS (commercial off-the-shelf) solutions. RFPs almost universally call for COTS solutions, but also include (often mandatory) requirements that cannot be met by any extant COTS product. Proposals reflect vendors’ offers to extend their pseudo-COTS applications to meet the new and unique requirements of nearly every incremental customer.
It is essential to understand that this is not customization. Customers do not receive unique one-of-a-kind versions of the product. Rather, the base feature set is expanded to incorporate incremental requirements. Of course, features sometimes conflict. One customer wants multiple dispositions, another wants to force a single disposition. A configuration option is added. Up to a point, this is perfectly reasonable. But when the incorporation of optional configurable features becomes the automatic response to every new requirement, the result is geometric growth in complexity. Effective testing becomes impossible. Defect rates rise.
Real COTS software usually alternates major new feature releases with bug fixes and improvements to performance, manageability, and usability. However, public safety vendors are contractually beholden to an endless backlog of new features. As a consequence, every release is a new feature release. Bug fixes, performance, manageability, and usability suffer.
Users delay upgrades and often skip release levels in response to the frequency with which new revisions introduce errors (in functions that were working just fine). This creates a perverse incentive. When existing customers resist upgrades, and new customers demand the latest and greatest, all of the development effort goes to new customers and new requirements. In the worst case (yet entirely realistic) scenario, a new feature that is of questionable value to a single new customer takes priority over a performance improvement that would benefit hundreds of existing customers and save countless hours, dollars, and errors.
Both public safety vendors and their customers are, at the same time, perpetrators and victims of these deeply ingrained practices. Neither can hope to affect change alone, and there are others whose interests may lead them to oppose constructive change. Procurement bureaucracies and consultants make a living as intermediaries between producers and consumers. Each of the parties has ample room for improvement.
Vendors should stop over-promising. But in a competitive marketplace, the one who does the right thing first will be crushed by their competitors. Industry associations, such as IJIS Institute, have study groups working to recommend industry-wide procurement reform. Some vendors are beginning to provide feedback for RFPs they no-bid, highlighting some of the worst problems. We believe an industry-wide code of conduct that raises the bar for vendor representations and disclosures would be useful.
True SaaS (software as a service) cloud solutions help by forcing all customers onto a common release cycle, resulting in features that benefit the installed base getting higher priority.
In an ideal world, smart software developers who understand the tradeoffs between complexity, quality, and performance would negotiate with users to find the minimum feature set that gets the job done. Almost everyone uses some variant of agile development methodology, the central benefit of which is that such negotiations can take place naturally as requirements are evolved in an iterative process. But in public safety procurement, in which every detail of the requirements must be pre-specified and developers are prohibited from any contact whatsoever with users. There are processes for negotiated procurement that enable more collaborative development. Unfortunately, the pretend-COTS requirement is often based in statute.
If the process can’t be fixed, then buyers have to be smarter about requirements. Here are a few examples from a real RFP (slightly altered to protect the guilty):
These are detailed specifications, not requirements. The first item suggests requirements that are obvious for a CAD system. Specifying the exact key sequence through which these functions must be accomplished is simply ridiculous. It precludes solutions that might be more usable and more intuitive. Requirements should state the essential processes that users need to carry out and, in general terms, the manner in which the system may support them, such as delivering essential data.
The second requirement appears to say that the new system must work exactly the same as the existing system, but provides no information as to the purpose of the actions. Requirements should explain the challenges users face and solicit solutions, allowing maximum latitude for innovative approaches.
Both the quality and the quantity of requirements should be closely scrutinized. When RFP boilerplate is cut and pasted from one RFP to the next, eventually every RFP includes every requirement that anybody every contemplated. The result: everybody builds the same designed-by-a-committee product. No requirement should ever be included in an RFP unless it represents a real verifiable user need! Boilerplate requirements increase costs and reduce quality.
Cloud Computing Explained
by Mark Fetherolf, Chief Technology Officer, InterAct
Cloud computing brings a sensational array of opportunities to the public safety community, not only to eliminate the cost of massively redundant infrastructure, but also to open communication channels that have long been blocked by incompatible information systems. Interagency dispatch, coordinated response, data sharing, workload balancing, disaster recovery, unified analytics, and connecting in new ways with the public are among the most exciting.
Cloud computing makes it possible for public safety practitioners to:
Save money by eliminating the redundancy of everyone having their own on-premise systems;
Share information and collaborate easily and naturally;
Have ultra-high-availability systems and advanced security;
Unfortunately, cloud jargon has become a source of confusion. Depending on who is using them, the terms have a variety of meanings. And sometimes the confusion is intentional:
The purposeful and sometimes deceptive attempt by a vendor to rebrand an old product or service by associating the buzzword “cloud” with it.
If you have ever done a Google search or ordered from Amazon, you made use of cloud computing. But what is cloud computing really?
Cloud computing technologies were developed originally to make it possible for Internet applications to support large numbers of users efficiently and economically. At first they were highly complex, expensive, and affordable only to the largest service providers. In recent years, cloud computing tools have evolved. Today, they are more affordable, less complex, and applicable to a wider variety of applications.
The term “cloud” comes from the symbol used in network diagrams, like the one below, that shows workstations connected to a server. But, despite the eye-catching cloud, it may or may not depict cloud computing.
When agencies use shared information systems, rather than operating separate facilities and applications, they can save up to ninety percent of the total cost of ownership. The more participants, the greater the savings. This being the case, one might imagine that agencies would be clamoring for shared systems.
But, new systems are acquired infrequently, and they are usually financed using grants or capital funds that are are separate from operational funding. Consequently, for an individual agency, reducing the cost of systems does not necessarily mean more firefighters or police officers.
Savings accrue most prominently to states and the federal government, consequently grant programs are being structured to favor various forms of consolidation. Similarly, county governments are using budget and political pressure to force municipalities to consolidate systems and eliminate redundancy.
But there are operational benefits for individual agencies, the value of which often exceeds the cost benefits that typically motivate systems consolidation.
Not only do neighboring call centers and the agencies they dispatch share a common operating picture, but they can initiate common coordinated action. For example, incident assignment and status routes instantly to coordinators of a multiagency response in two or more dispatch centers.
Interagency dispatch activation, under mutual aid and automatic aid agreements, is fully automated. On a shared system, workflow can be tailored to reflect standard operating procedures and ensure compliance.
When one location has an unexpected high call volume, workload can transfer instantly to another facility that has capacity available.
In a disaster, any facility can serve as a backup for any other.
Unified reporting and analytics across agencies provide a complete picture of regional response effectiveness, and provides a basis for regional process improvement and measuring progress.
In the near future, with NG911 systems based on I3 PSINets, it will be possible to route calls dynamically based on the location and availability of response resources, virtually eliminating time-consuming call transfers.
Relevant information is delivered to responders where and when it is needed. For example, a license plate query returns not only vehicle and owner information, but recent queries, citations, and involvements from all cooperating agencies.
Officers operating outside of their home zones are automatically notified of urgent situations nearby regardless of agency affiliation.
Situational awareness is available to all participants in a multi-agency response.
Messages and status information attached to shared incidents are immediately available to all parties, even when there are multiple dispatch centers involved.
Task forces and special investigations can be easily set up to share records and case data across agencies.
have a snappy reply to Friedrich Wilhelm Nietzsche? Tweet @towhichisays
You get the idea.
Maybe my list will be included someday in a List [[[[of lists] of lists] of lists] of top 10 things]