I got up around 5 a.m., made a coffee, and, as usual, started talking to myself. Then I decided to write this whining article.
I am currently struggling to explain to a new client the scale of the disaster in their web application. Development started in 2014 and continued on and off over the years, changing direction and developers several times. Now they plan to fix it up a little and put it into production within two months.
The client sees that the main workflows appear to work on staging. What they do not see is the bad joke under the hood and everything that will go wrong in production once real users arrive.
And that is nothing compared with security holes such as using eval() on browser-controlled input, unauthenticated routes that expose sensitive data or allow records to be deleted, SQL injection vulnerabilities throughout the application, and so on.
I do a lot of work on legacy applications and almost never suggest that a client start from scratch, but in this case I am wondering which option would be worse.
The client is pushing back. His buddy—some unknown AI chatbot —is advising him that a rebuild is out of the question. In defence of that AI, I can only say that it probably does not have the full context or understand the true scope of the issues.
Why am I accusing an AI chatbot when it may be completely innocent?
The client’s latest email was waiting in my inbox when I woke up. It stated that the unauthenticated routes were not an issue because they would not be indexed.
The client has hired a DevOps engineer. I refuse to believe that this conclusion came from him. If it did, he should be fired twice.
That reminded me of another client who had already discovered what cheap, low-quality software can really cost.
A while ago, I was contacted by a law office with five or six attorneys. They relied heavily on an Outlook add-in that synchronized tasks and calendar items from an Access database into Outlook.
The add-in had worked for years and then suddenly began exhausting memory and making Outlook unusable. Attorneys started missing appointments, and the office eventually hired someone to perform part of the synchronization manually as an emergency measure.
The original add-in started a new synchronization cycle every five minutes without checking whether the previous cycle had finished. When the network became unstable, some cycles remained in progress while new ones started. Each cycle scanned the same 30-day window and processed the same TaskIDs again.
The add-in also failed to enforce a simple rule before saving: only one Outlook item should exist for each TaskID.
On the first day of the network problems, the add-in created 1,298 Outlook items for only 211 distinct TaskIDs. Every TaskID was duplicated. Some appeared as many as 15 times.
As the overlapping cycles continued, the number of Outlook items grew into the hundreds of thousands. At its peak, the office had more than 600,000 items. The growing backlog increased memory usage, slowed every synchronization cycle, and eventually made it impossible for a cycle to finish before the next one began.
A relatively small design flaw had turned into a self-reinforcing failure that effectively disabled Outlook for an entire law office.
They chose the cheaper option and ended up paying the original developer, the person doing the manual synchronization, their Access developer to dig in the wrong place, and finally me to fix the damage.
And considering that this was a law office, I can only speculate how much their business suffered before they even realized Outlook was not working properly.
If you made it this far, thanks for reading my whining.
Top comments (0)