Aging web applications that no longer function at 3:30 when every user runs their end-of-day reports? Database-driven system requires a $5k per month cloud presence to support just 100 simultaneous users? Backend services so slow that your users' browsers are timing out before the page renders? I love fixing that stuff.
Employee churn, changing requirements, and rushed deadlines breed acres of disappointment. Users want software to do its job and stay out of the way. Systems that consistently do anything less are simply unacceptable.
Sometimes, the laser focus of a company's development team on their to-do list keeps them from properly engaging with their managers on a should-do list. Poor test coverage, non-optimized code that over-taxes databases and other system resources, and multi-day update procedures are the result. It's known as technical debt and most projects are swimming in it.
The fact is, at some point, technical debt snowballs into a significant recurring cost to a company in the form of reduced performance of business processes, increased development costs, and greater customer acquisition and retention costs.
If your systems and/or your system developers are slower than they could be, you're simply burning money.
The problem isn't always clear and neither is the path forward. Sometimes, the first step is simply to engineer some visibility into the system so the root cause of the problem can be properly ascertained. Sometimes, we discover the cost required to repair something outweighs the benefit of the fix and we have to look elsewhere to try to get system performance to match expectations. The important first step is to gain a better understanding of the problem.
But more often than not, eliminating technical debt and optimizing software systems requires nothing more than an iterative cycle of identifying problems and bottlenecks and correcting the issues found. It's not uncommon at all to find out that a business system is hitting the database 1000 times harder than it should to do its job and the fixes consist of low-hanging fruit of the sort that's easily found with simple profiling tools and log analysis.
The approach is much the same whether we're creating a system from scratch or simply bringing an existing system in line with expectations.
What problems will this project attempt to solve? New systems are frequently attempting to automate or augment an existing business process, so the problem is simply that. The problems facing owners of existing systems typically have to do with wanting to drastically reduce the costs associated with non-optimized software, significantly improve performance, or both.
What's the best way forward? There can be a lot of calculus to a proper answer to this question.
The cost of the approach itself in terms of developer-hours and licensing fees is a big concern but there are maintenance concerns too. If your underperforming system is written in a language that's been long forgotten and it only runs on hardware that's no longer available, then it's time to consider a wholesale rewrite. On the other hand, if the situation is less dire and your web application is simply aging out of its original design constraints, there's usually a way to t ransition a functioning system gradually from obsolete and plodding to modern and nimble without the risk or a complete overhaul.
Sometimes, the best approach considers quite a bit more than development, maintenance and performance. Timing related to sales and marketing efforts, layoffs, investors, etc. can have dramatic effects on a project's constraints.
I maintain a frank and well-informed conversation with clients throughout the planning and execution phases of a project to ensure that expectations are met. And if expectations and/or requirements change along the way, that the project scope changes with them immediately.