Unbelievable. Look, an “app” ain’t an “application.” It’s nothing more than a client computer’s link to a server. The actual “application” is on the server. Thus, either the problem is with the database on the server, or the client link that was built.
My guess is that the problem is with the database query. Most likely, they got a Cartesian join. It results in a catastrophic forked replication that causes the machine to duplicate every calculation, i.e., 2 -> 4 -> 16 -> . . . loops.
I once tried to compile a tally that should have taken 15 minutes. Three days later, the damn thing was still trying to calculate.
Let me be clear: You cannot develop an application utilizing a production server. Three servers are utilized to design a bullet proof application:
1. A development server
2. A test server
3. A production server
When a project manager attempts to omit # 1 and/or #2 (as it actually is 3 times more expensive in hardware), you’ve created a disaster and high probability of a catastrophic failure in the deployed application.
The reason is simple: All computer tools comprise three elements: hardware, operating system software and application software. Furthermore, the hardware comprises assembled sub-assemblies that contain firmware. Firmware isn’t anything except hardware components with pre-programmed operational function.
That’s literally all you need to know about how computer things work. So, when you’re developing an application, anything can go wrong. In the three tier deployment of an application it’s likely, when there’s a glitch, you can verify where the problem isn’t. That’s why there’s a development server and a test server.
The thought process is: 1. I have a problem. 2. I fixed the problem. 3. Did it effect anything else, creating a different problem (i.e., ‘did I accidentally hit the incorrect key on the keyboard making a typographical error’).
But, after you develop the application or fix a glitch, you’ve got to test it … real time, just like it’s hot in the real world environment. And, it must be exactly the same as the production server.
When you do that, you can usually catch most glitches. But, God help you if you skip testing and use the production server for a test. You won’t do that because the production server must be stable as a rock and 99.9999% reliable. Also, it has to be the exact duplicate of the test server. And, Microsoft always updates shit, whether you want it or not in most instances. Shit just stops working.
My guess is the back end was Microsoft (the production server) and the development or test server (if they used one or two — which I doubt). Given the security needed for the client application, SSL and whatever else is utilized to authenticate the client, you’ve got a world of possibilities that is simply FUBAR if and when you take a short-cut. There’s a single point of failure.
$60,000 to develop that sort of application is way too little and short-term skimping on resources (low-balling a bid), results in disappointments, big time.
I AM NOT A GENIUS
You must be logged in to post a comment.