It’s happening more and more lately.
-
Me: . . . Okay, so I understand a little bit about your project goals and how they fit in with your business needs. . . Can you tell me, if you know, what technologies your current application was built with?
Client: Um. . . I’ve heard some of the folks say “PHP”. . . does that make sense?
Me: Sure does. Any idea what version of PHP and which framework it might be leveraging?
Client: Oooh, I don’t know. . . I can get that for you though. . .
Me: That’s okay. How about this: How old is the application and when is the last time you did an update?
Client: Well, we developed it in 2007 and we had a person who worked on it for just a couple years after that but they aren’t here anymore. . .
Software development has moved through several “ages” as both technical innovation and the cultural evolution driven by those technical innovations has moved from the early adopters through the late adopters and permeated our expectations of what technology is.
But, now, we’re seeing a wave of projects driven solely by applications just getting long in the tooth. A little more than a decade ago, as a result of the dot-com boom, software left the domain of tech-centric, tech-dependent companies and was widely adopted by businesses of all types. Companies made a push to take operations traditionally done manually or in spreadsheets and created enterprise applications that became the engine, and face, of their employees’ workday.
At the time, the technologies used were contemporary and the methodologies for implementing those technologies were cutting-edge. But these companies frequently didn’t have the experience of being a software/tech-centric/tech-dependent company to know that software is a dynamic product — which, by definition, always requires updating, maintenance, and, eventually, rewrites. There was no plan developed for evolving their business solution over time to keep it current and healthy. My experience is that these companies viewed their software more like a copier and didn’t see software for what it really is — a unique business asset requiring diligent and consistent care and a long-term maintenance plan.
Applications that have been allowed to atrophy over the course of a decade, or even 4 or 5 years, present a unique set of challenges and they require a different kind of partnership between the developer and the client.
The triggering event to reach out to a developer for work on an older, unmaintained application might be:
- The client may desire to integrate a new third-party piece of software or hardware and their current application doesn’t meet minimum-supported specs.
- The client may be wishing to update a UI/UX that feels dated and cumbersome.
- The client’s business needs have changed and the application is currently being user-hacked to make it fit the new business needs.
- The application has suddenly begun throwing critical bugs.
- The application has been hacked.
- The client has decided to expose some or all of their enterprise application or data to their clients through a user-portal.
The problem is that, frequently, the client expects that these issues/needs can be simply built upon the current solution. Or, if they understand that some updates may be needed, they underestimate just how far behind their application lagged.
In the case where the application is throwing critical errors or has been hacked, the immediate desire is to button up the vulnerability or patch the application and get employees productive again. In those instances, we always attempt to triage the application. However, it should be understood that triaging may not be a) quick, b) optimal, or c) without its own repercussions with respect to performance or bugginess.
But for less critical items, and certainly once the critical issues are patched, we recommend a considered discussion of the options for dragging your application into the Current and addressing your business needs. The discussion should include a few important steps and encompass a thorough discussion of your long-term business plans in order to ensure that the right problem is being solved in the right way — where “RIGHT” is specific to your company.
Start with a code analysis — A developer should spend time really looking at your code and its documentation. We can’t make solid recommendations unless we understand the state of your code.
Do a mini-discovery phase — It’s often very helpful to examine user’s current needs. What has been the bane of their workday for the last few years? What systems do they wish were connected? Would it be helpful if part or all of the application was responsively designed so that it worked on a mobile device? Has your CEO been ruminating about how AR could be integrated into the production line? Have your client’s been asking for something ad nauseam that you’ve been unable to give them because of limitations of your current system?
Explore contemporary technologies and implementation approaches — 6 or 7 years is a long time in Software. There have been major advances in what software can do and how it does it. This can open up new functionality and integration opportunities for your application, providing an increase in usability and efficiency.
Create a plan to move forward – With your development partner, create a plan for achieving your business goals weighed against the reality of your current application and the overall road map of your business. The plan usually centers around one of three approaches but can contain infinite customizations.
- Focusing on a rewrite of the application – which may be the best and cheapest approach — while limping the current application along; OR
- Doing a full refactor of the application including updating the versions of the technology and any dependencies (APIs and libraries, for instance, which may need to be updated or substituted) to bring it current with supported versions and to address any architectural issues. This can be a tempting choice but contains a fair amount of risk and may become a case of throwing good money after bad; OR
- Doing a phased rewrite, where certain core features are rewritten first and the user toggles between new and old features to complete their workflow — which can spread out the cost of development but move a business towards currency and desired functionality; OR, FINALLY,
- There may be an off-the-shelf solution now that would cover most or all of what you need to do.
