I know we've all heard the expression "Poor planning on your part does not constitute an emergency on mine", but nothing could be further from the truth. Luckily there are some people out there that still understand this concept.
I was tasked with installing a certain piece of software, this directive came practically from the top of the institutional food chain, without revealing too much information, I became suspicious of the software before downloading it, and did my due diligence. There have been reports of ad-ware and spy-ware, as well as censor-ware being included with the official version of the software.
The end-user who had been told to get this installed understood my concerns, and we have started looking for alternatives. It's nice to see people who still "get it"
Wednesday, June 1, 2011
Programmer <> Software Developer <> "I Write programs"
This is one of my pet peeves, and it keeps showing up in my everyday life as a support guy. There is a massive difference between "good" programs, and "bad" programs.
Let me start with some background about me, I took two and a half years of a computer science degree, I can write programs (I may not be that gifted) but I understand technology, and have run into many of the pit-falls myself.
What do I mean by "Bad" programs? mostly, ones that don't follow good practices, ones that appear to have been written in someone's basement. Don't get me wrong, some of these programs may be very good at what they do, but they are a complete BEAR to support.
2 examples, one bad, one worse.
Bad: A financial budgeting/forecasting suite. We were handed this software, and informed "It will be installed" the purchase had already been completed. So we look into it... It needs a SQL database, good... Wait WHAT... It needs DB_CREATOR rights to the Database server? NOT GOOD, but we can work around it by creating a whole separate instance of SQL, just to run this software, moving on, We have 15 seats, Okay. We can activate it 17 times before we have to call to get more activations (provided we have an active support contract)? wait, there's no way to de-activate an install once it has been activated?
Worse: A specialized contact database for placing students in practicum type locations. The "Program" consists of 2 access databases, DB1 resides on a file-share, and stores the data, DB2 is "installed" on each user's computer and provides the UI to DB1. Aside from my dislike of Access as a database system, there's one MAJOR problem that we ran into, we had to move DB1 as we were retiring the original server it resided on. the UNC path to DB1 had been hard-coded into DB2, necessitating us to contact the "vendor" and having him provide a newly edited DB2 that pointed to the new path. Very very rarely should anything ever be hard-coded.
Enough for today, forgive the rant.
Let me start with some background about me, I took two and a half years of a computer science degree, I can write programs (I may not be that gifted) but I understand technology, and have run into many of the pit-falls myself.
What do I mean by "Bad" programs? mostly, ones that don't follow good practices, ones that appear to have been written in someone's basement. Don't get me wrong, some of these programs may be very good at what they do, but they are a complete BEAR to support.
2 examples, one bad, one worse.
Bad: A financial budgeting/forecasting suite. We were handed this software, and informed "It will be installed" the purchase had already been completed. So we look into it... It needs a SQL database, good... Wait WHAT... It needs DB_CREATOR rights to the Database server? NOT GOOD, but we can work around it by creating a whole separate instance of SQL, just to run this software, moving on, We have 15 seats, Okay. We can activate it 17 times before we have to call to get more activations (provided we have an active support contract)? wait, there's no way to de-activate an install once it has been activated?
Worse: A specialized contact database for placing students in practicum type locations. The "Program" consists of 2 access databases, DB1 resides on a file-share, and stores the data, DB2 is "installed" on each user's computer and provides the UI to DB1. Aside from my dislike of Access as a database system, there's one MAJOR problem that we ran into, we had to move DB1 as we were retiring the original server it resided on. the UNC path to DB1 had been hard-coded into DB2, necessitating us to contact the "vendor" and having him provide a newly edited DB2 that pointed to the new path. Very very rarely should anything ever be hard-coded.
Enough for today, forgive the rant.
Subscribe to:
Comments (Atom)