More than a few years ago, I started what was to become a lifetime career in technology. My first job as an engineer was in aerospace avionics, where a senior colleague told me a story from his own early career working on the original F-14 Tomcat fighter jet.
After months of hard work, his team reviewed a prototype design with some experienced Navy pilots who hoped to fly the aircraft. Five minutes into the presentation, the pilots asked about a particular feature.
There was an awkward silence from the presenter. After a few seconds, he said, “Umm… nobody told us this was a requirement.” One of the pilots shot back, “Why would they? Everybody knows that’s a requirement.”
This summarizes the problem with custom software. A software team can be software experts, but they can never be experts at the end users’ jobs. This is especially true when designing municipal management software for our home state of New Jersey, where each of our 565 local governments has its own way of doing everything.
The “Framework Problem”
To understand why custom software development seems to always take longer than planned, you should understand how software is developed. First comes the framework on which functionality will be built. To use a construction project analogy, the framework is the foundation on which a building will eventually stand.
Once the framework is developed (which can take weeks or months), it’s time to develop the functionality itself. When a prototype is running developers sit down with users for “alpha testing” or “User Acceptance Testing”.
Here’s the big problem… very often, a custom software project gets to this point without anyone realizing that a critical required feature is missing. What seems obvious to users may not be obvious to developers. During testing, an experienced user might ask about a missing critical feature. If everyone is lucky, it can be fixed with a few new lines of code.
But not everyone is so lucky. Frequently, an alpha tester finds a critical missing feature that requires a fundamental change to the framework as well as all the software built on that now-obsolete framework. If it’s October and you discover that you need a framework change, the software you planned to use next January might not be available until August.
The “Support Problem”
At some point, every software user needs a little guidance. When municipal employees need it, they usually need it in a hurry. That’s not possible with custom-built software.
Even if your software was developed using the best possible design discipline, where every nuance is sufficiently documented, support team personnel can never become “experts”. There are no frequently asked questions, knowledge bases nor top-of-the-head answers. Support people wind up slogging through masses of technical documentation, looking for clues. That’s if they’re lucky; custom software documentation is often skimpy, to put it mildly. It’s not uncommon for technical support answers to take days, and some can take a week or more for satisfactory resolution.
The “Evolution Problem”
Here’s a quick question for anyone who’s worked in a municipal government department for five years or more: do you perform your job the same way today that you did five years ago? The answer here is exclusively, “no”.
Municipal governments evolve constantly due to changes at the state level, to resource and staffing issues, to changing expectations from residents and councils, and a hundred other factors. This is a problem when you’re depending on custom software.
If you’re paying “custom software” prices, it’s because you needed a unique software architecture. If yours is truly a custom architecture, some of the fundamental functionality is “hard-coded” into it. That’s why process changes can lead to unpredictably expensive software modification projects. Nobody ever built a solid governmental career by presenting unanticipated four- and five-figure expenditures for approval.
The key to stable, cost-effective software is an architecture designed to address any combination of requirements rather than a particular set of requirements. An architecture like this offers significant advantages to buyers and users alike:
- While development is more expensive, those costs are amortized over several years and many clients, and the end user’s price per function is lower.
- Clients are never “alpha testers”. The platform can evolve and be used in new ways, but this never requires large-scale architecture changes. User-requested tweaks occur in minutes or hours instead of weeks or months.
- Support teams can be trained on a single platform and learn the details of the modular applications built on it. Support people build up expertise and share it with teammates, so questions can be answered in minutes instead of hours or days.
- The larger architecture investment enables lower costs, faster deployment and more stable products when peripheral apps (e.g. mobile apps, web-based portal applications) are added to the platform. All apps can use the same data set; there’s no integration cost because there’s almost no integration. In the case of the SDL platform, these useful apps are included for free when a town deploys SDL Desktop.
- Custom projects are often quoted with lead times of several months, and deployment cycles of up to a year and a half. The flexible SDL platform has been fully deployed (from a fresh start to productive usage) in a single week.
- Finally, when process requirements suddenly change for a government team, the software can change just as quickly. When a licensing process is moved from one department to another, or when multiple users suddenly dream up a process change that makes their jobs more efficient, the software can change (sometimes in one day) without unexpected change notices and invoices.
One Last Analogy
Many of us use word processing software every day. We each configure it to our liking and choose features and workflows that make us most efficient, but many of us use the exact same application; it’s been proven, tested, debugged and has evolved over the years.
It’s theoretically possible to commission a custom-built word-processing program, but none of us will ever do that. We’d be waiting for months, we’d pay a stratospheric price to get something that’s impossible to change or support and we’d have no more functionality than we would have otherwise.
The same principles apply to municipal management software. No matter how unique your needs, a stable, cost-effective, supportable platform can be yours without resorting to custom solutions.