Dear Ammo,
A third party developer my boss has brought in, designed a "Better" System than our ASP.NET + MSSQL Server 2005 website we're using now.
Here are the relevant specs:
Is there any glaring problem with his solution short of the ancient tech? Thread safety etc?
Let me put it this way, "What can tell my boss (who's only partially technical) to blow this code out of the water?"
Thank you,
Vindictive Developer :)
Synching issues dealing with a seperate xls datastore and sql server 2005? On our IIS server, classic asp pages are prohibited by default. Maybe that's a sign lol.
How about terrible performance, since Excel is not designed to be used as a database? Tell your boss Excel isn't even a single-user database (that's what MS Access is), let alone a multi-user database designed for high, concurrent performance.
And of course by using pure ASP you're losing access to all of the libraries .NET framework (which of course is what all library developers in the MS ecosystem are focusing on). But you asked for 1 reason, and the first is better.
Ummm.... it lacks scalability: You could only have a few users. Is the data important?
I would go with the mantra that those are the wrong tools for the job (assuming they are in your case). It'd be like using a screw driver as a hammer. For one nail, it might work with a lot of sweat and tears. For a real project, through, this is likely doomed.
I'd boast about the tools you are familiar with--how much better the tooling is in terms of performance, security, maintenance (esp. maintenance cost).
You could say something like he's paying someone to write a new app with decade old technology which may not be supported for much longer (if it still is...).
Is an Excel spreadsheet even going to handle concurrent transactions correctly? It wasn't designed for this kind of thing, and I wouldn't hold it responsible if it did something bad (like only letting one ODBC connection in at a time, or not properly locking concurrent updates).
That excel file's going to get corrupted in a hurry with many people hitting it at the same time. The scalability of Excel as a backend datastore is almost non-existent. It has a hard enough time keeping data integrity with its native Shared Workbook feature...
BTW- Is this third party a relative of your boss??? Yikes...
Excel should never be used as a data store,
It is not a database
It will not handle multiple users at once at all
No support for transactions, so if an error occurs in the middle of a odbc call the excel file could end up trashed. (Even access would be better then using excel and that isn't saying much)
Excel is a spreadsheet, designed for analyzing data, not for storing data.
The ancient tech is itself a glaring problem. Will you be around forever? It will be very difficult for the boss to find new developers to maintain something like this. The tech world has moved on.
Straight from Microsoft: http://support.microsoft.com/kb/195951
IMPORTANT: Though ASP/ADO applications support multi-user access, an Excel spreadsheet does not. Therefore, this method of querying and updating information does not support multi-user concurrent access.
Allain, as well as the great technical reasons that have come out here, I think you need to ask yourself "why did the boss do this?"
Perception is reality, and if your boss is only partially technical, then purely technical reasoning may not get through.
Apart from the glaring architectural weaknesses, is there some functionality in this monster that makes it more appealing to your boss? Generally people don't do stupid things on purpose, it may serve you well to consider where you boss is coming from before you go making a CLM.
Here's what you can tell him: Remind him of the nightmares that happen when two or more people need to edit the same spreadsheet at the same time. Now tell him to imagine that multiplied by a hundred people who can't call each other to tell them to "close the spreadsheet so I can update it". That's what it will be like.