| Author |
 Topic  |
|
|
AnonJr
Moderator
United States
5768 Posts |
 Posted - 15 December 2005 : 10:17:01
|
I'm struggling with a decision at work relating to: evaluating and buying, or continuing to build the Learning Management Software (LMS) here at the hospital.
Some history first:
Before I started working here there were certain annual requirements for all employees. They had to attend classroom classes like "Fire and Safety" and "HIPAA Compliance" every year for their evaluations. It was a mess. There's only so many rooms available, only so many instructors available, and 4,000 employees.
About 5 or so years ago my predecessor convinced IS to let her put some of the content up on the company's intranet and set up a little PERL-based quiz at the end. They agreed, and about 5 of those annual courses were placed online.
Fast-forward a couple of years, and everybody loved the idea. There were nearly 100 online courses - and no integrated management system. The programmer before me had to convert all the presentations and tests to HTML, put a link in all the appropriate areas, put a slightly modified version of the PERL script in each test's folder, and once a month clean out the logs. (hold on to this thought for a minute)
Two years ago, she left for greener pastures and I was hired to take over the position of "Computer-based Training Programmer". Unfortunately she'd been gone for 2 months before I'd been hired. I came in and found the system described above. And it was a functional mess.
The PERL scripts graded the tests and appended them to the end of the log file in HTML format, which meant that it was next to impossible to re-extract the data programmatically. If you forgot to change out the logs once a month you ran into memory issues (this was all running on an old NT4 server that was also hosting the rest of the intra-web site). This would cause the server to crash and any open logs would get corrupted. Sometimes beyond any recovery.
People were supposed to print out the pages that stated they passed and on what day/time etc. (we've been referring to them simply as the verifications). But, more often than not they didn't print them, or they lost them, or the printer gremlin ate them, or they didn't have a printer set up and couldn't be bothered to call IS to get it installed (that's a whole other topic for another time  ). This left yours truly to hunt through all the HTML logs for their name (which they either spelled wrong, or entered a different name, or anything to make it next to impossible to find it). That's right, I had to hope they gave me the right month (guess how often that happened) and search that month's log for their name, and send their manager an e-mail stating that they passed and on what date/time. It was a time consuming mess.
I started work on our current system and got it running in Nov. of 2004. All the content, tests, and records are stored in a string of Access databases. I've got a search page set up so the managers can try and find their employee's verifications (people who still can't type in their own name correctly or consistently), and life is ok.
Its time to make some upgrades and fix a few things, but before I can I need access to more tools. IS wouldn't let me use any databases other than Access. I can't make or install components (compiled ones any way - I've got a few scrips functioning like components). It wasn't until one of the Dr.s got involved that they even discussed granting me the privilege of using SQL Server.
As an unfortunate side-effect we now come to my present dilemma. These meetings with IS have re-opened the debate over buying a package or continuing with the home-grown solution. I looked at this before I made the current system and what I saw wasn't encouraging. I still think that we should continue with the home-grown, but IS doesn't want to provide support (they'd rather have a vendor to call) and they are scared of getting screwed if I leave and no one can manage/upgrade the program (apparently its happened with some other programs).
The pressure is to buy. I don't think its as good an idea as they think it is, but before I explain my reasons I'd like to hear what you guys think. Am I too 'attached' to this project? Am I biased by nature as a programmer? Is it time to just buy it? Or should I continue to build? |
|
|
HuwR
Forum Admin
United Kingdom
20600 Posts |
Posted - 15 December 2005 : 11:00:00
|
You should continue to build, buying an off the shelf package will not help, you will still end up in a mess and the vendors won't actually give you any help if things go wrong.
A newer more up to date system will by it's nature be more robust and require less interference, if they think you leaving will put them in a bad position, assure them that any new code will have the proper documention required for someone to take it over, you are after all a professional who takes as much pride in what he does as they do in their jobs. |
 |
|
|
AnonJr
Moderator
United States
5768 Posts |
Posted - 15 December 2005 : 12:50:28
|
That's been my line of thinking too. I told them to give me whatever standards they need to assure themselves that there will be adequate documentation. Also, I've seen the support we've been getting from the vendors of other systems... I'll just leave it at that. (Though in the defense of one or two of them, our IS didn't exactly follow all the systems recommendations that were given to them either due to "cost issues" now we have "performance issues"... go figure.)
I also agree with what Joel Spolsky wrote in one of his articles - particularly these two quotes:
quote:
And that's where I learned a key lesson in software architecture: for your most important, mission critical stuff, you have to use a tool that is one level lower in abstraction than ideal. For example, if you're writing a cool 3D shoot-em-up game (like Quake, around the same time period) and your key number 1 differentiator is to have the coolest 3D graphics, you do not use whatever 3D library you can find. You write your own, because it's fundamental to what you do. The people who use 3D libraries like DirectX are using them because they are trying to differentiate their games on something other than 3D performance. (Maybe the story line.)
quote:
When I sit down to architect a system, I have to decide which tools to use. And a good architect only uses tools that can either be trusted, or that can be fixed. "Trusted" doesn't mean that they were made by some big company that you're supposed to trust like IBM, it means that you know in your heart that it's going to work right. I think today most Windows programmers trust Visual C++, for example. They may not trust MFC, but MFC comes with source, and so even though it can't be trusted, it can be fixed when you discover how truly atrocious the async socket library is. So it's OK to bet your career on MFC, too.
You can bet your career on the Oracle DBMS, because it just works and everybody knows it. And you can bet your career on Berkeley DB, because if it screws up, you go into the source code and fix it. But you probably don't want to bet your career on a non-open-source, not-well-known tool. You can use that for experiments, but it's not a bet-your-career kind of tool.
Though I will admit to being a little biased in favor of the build option because I think that too often people would rather spend the money upfront and fix the processes to match the program rather than spend the time and energy and make a program that fits the processes. The only exception is when you need to fix a bad process - but that can be done in the build too.
I've been doing a lot of thinking about it and I just need to find a good way to explain my position in a way that doesn't just sound like "in my professional opinion..." |
|
|
|
pdrg
Support Moderator
United Kingdom
2897 Posts |
Posted - 16 December 2005 : 05:56:39
|
| My 2p - if it was a fresh build/greenfield project I'd buy COTS (commercial off-the-shelf) and change the way the company worked to fit in with the software - this way 1) the testing has more or less been done for you already, 2) you're not introducing new code (= new bugs), 3) you get the benefit of the collective experience of many previous users who've fed back enhancement requests already 4) fast to deploy 5) usually cheaper than your hourly rate to write something similar. If you have inherited a partial system, it may be preferable to carry on with it, just try to be considerate of whoever comes along after you, now you've seen what it's like to pick this stuff up midway ;-) |
|
|
| |
Topic |
|
|
|
Topic Locked
