• JS (unregistered)

    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?

  • no name (unregistered)

    sqrt(1^2) + 1 (damn captcha)

    :D

  • (cs)

    Not getting it - the WTF is a poorly written obsolete system???

    OIC

    WTF??

  • bramster (unregistered)

    It wasn't Purdue, by any chance?


  • (cs) in reply to JS
    Anonymous:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?


    The former.  I find that having a reflection in a mirror helps greatly with shaving.

    "middleware" seems too often to have the wrong initial vowel.  "muddleware" would be a better fit.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to JS

    Anonymous:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?

     

    I would like to be the company that got it right cause when the university needs some maintenance or other systems created then I will be the company that made several times more money.

  • (cs)

    Mother of g*d! Now I understand why I'm having trouble getting into the building every day...and all this time I just though the guards didn't like me.

  • Colin (unregistered)

    I've been reading this site for a while now and pretty much every posting has this in common: they either don't know of a tool or if they do then they don't know how to use it.

    But both paths can be quite comical though.

  • (cs)

    Wow; a company that lands a contract for an enterprise-level job, and they seem either ignorant of the advantages of a database, or suspicious of using one.

    I would like to see the inside of one of those 'text_files'.

  • (cs) in reply to bramster

    I would hope it wasn't Purdue.  The students there could do 10X better than this.

    That is, however, exactly what this sounds like.  It sounds like the quality of work you would get with a mediocre school's senior project.

  • (cs) in reply to JS

    Many genuinely frightening things happen with these school card systems.  I was still in school in 2003 when my school rolled out it's new ID card.  I took mine to work, ran it through a magstripe reader, and low and behold, the only thing on the card was my student id number, and a counter so it read something like 99999999901.  The student id is printed on the card itself, and not something that is kept secret because it was no longer the SSN.  If the student lost their card, the system was 'secure' because the new card was issued as 99999999902.  You've gotta love that security.

  • (cs)

    Good lordy, how would they explain this to other places they were going to work ..Hey we can code just don't expect any new fancy, I make you life easier stuff!!!!

  • (cs) in reply to JS
    Anonymous:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?


    the company that got it right because reputation is very important in the long term and could lead to highly paid contracts in the future.
  • (cs)

    Were the original "programmers" former students?

  • (cs) in reply to Pastor_Of_Muppets

    s/it's/its

  • (cs) in reply to R.Flowers

    R.Flowers:
    I would like to see the inside of one of those 'text_files'.

    I don't think there was anything in the files themselves...they just represent values that SHOULD have been inserted into columns...in a table...in a [fill in the blank here].

  • (cs) in reply to JS
    Anonymous:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?


    The former.  They have a good reference and a future source of income.  Meanwhile, the latter has killed their golden goose and damaged their credit with the goose vendor.

  • (cs) in reply to Colin

    Anonymous:
    I've been reading this site for a while now and pretty much every posting has this in common: they either don't know of a tool or if they do then they don't know how to use it.

    You've heard "to a hammer, every problem's a nail." Well, this company has a nail, but no clue what a hammer is.

  • (cs) in reply to JS

    And I took all of that stuff for granted when I was going to school.

    The bit about the students figuring out that debits weren't processed until the next day is funny.  The closest we had was an ATM that spit out $10s and $20s and some dolt put $20s in the $10 container.  People were allowed to do 3 withdraws before going to the end of the line (well, until the party was broken up).

  • (cs) in reply to JS

    It depends, if work was scarce in my area I would rather be the one that made more money.  You can always pack up, move on and leave your reputation behind.

  • (cs) in reply to connected
    connected:

    R.Flowers:
    I would like to see the inside of one of those 'text_files'.

    I don't think there was anything in the files themselves...they just represent values that SHOULD have been inserted into columns...in a table...in a [fill in the blank here].

    I'm assuming the numbers are file names (that roughly correspond to a 'primary key'), and the contents would be column names - values represented in some way. For example, in the file '3040557', the content (in accounts/balances, for example) might be:

    balance=124.75
    last_transaction_date=03/04/2005

    or maybe just

    124.75
    03/04/2005

    Ken Nipper:
    Were the original "programmers" former students?

    I hope students would do better.

  • (cs) in reply to jackass
    jackass:
    It depends, if work was scarce in my area I would rather be the one that made more money.  You can always pack up, move on and leave your reputation behind.


    Well, at least you're honest.  Remarkably so, given your username.  :D

  • (cs)

    Overall the University would have been better off if they let the students write the system.  Make a part of large project in a software development or engineering class!

  • Ann Coulter (unregistered) in reply to emurphy
    emurphy:
    jackass:
    It depends, if work was scarce in my area I would rather be the one that made more money.  You can always pack up, move on and leave your reputation behind.


    Well, at least you're honest.  Remarkably so, given your username.  :D



    There's nothing contradictory about an honest jackass.
  • JS (unregistered) in reply to emurphy
    emurphy:
    The former.  They have a good reference and a future source of income.  Meanwhile, the latter has killed their golden goose and damaged their credit with the goose vendor.
    Ah, but the incompetent company only has to sucker people into buying their services every once in a while to out-earn the other company. A good reputation can help, no doubt, but reputations don't carry forever.
  • Bahamas Boy (unregistered) in reply to mrsticks1982

    [image] Anonymous wrote:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?

     

    I would like to be the company that got it right cause when the university needs some maintenance or other systems created then I will be the company that made several times more money.

     

    Good for you. But now, every day *I* go lauging all the way from the beach to the bank...

  • filesalot (unregistered)

    Of course a DBMS is the right tool for this job, but I don't think you can lay the problems of this system on the choice
    of flat files in a directory tree.

    You can go pretty far with a directory tree (it is a tree index, after all) as long as you keep the size of the directories small.
    For example, if user id #0123456789 was kept in the file

        01/23/45/67/0123456789

    Wasteful of space, but not horribly slow.  Subsecond access should be no problem at all.  And you could distribute this system nicely by user id, eg the last digit of the id is the backend server number, 0-9, to send the scan to, so there need be no problems with immediately debiting the user account.

    Sounds like the performance problem was due to the muddleware.

  • Krenn (unregistered)

    My personal guess...

    "Wait a minute, we have to pay a licensing fee to use a database in production?  Screw that, we can implement one on our own."

  • SJ (unregistered) in reply to JS

    The latter, because everyone else chose the former and I'm cool like that.

  • SJ (unregistered) in reply to SJ
    Anonymous:
    The latter, because everyone else chose the former and I'm cool like that.
     
    Dammit, Replied instead of quoted.
     
    JS:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?

    The latter, because everyone else chose the former and I'm cool like that.
  • Roger (unregistered)

    Alex Papadimoulis:
    For being all computerized, it worked slowly, taking about a second or two per scan. When used at student events, it would take 3-5 seconds per scan, if it worked at all. This was a bit of an issue.

    I am almost certain that the clients never specified the response time in the original specifications.

    Poor specifications == poor product == client's fault.

  • IRRePRESSible (unregistered) in reply to synesthetia

    Purdue Chicken has a University WTF!

  • (cs)

    The real WTF is that this is how Visual Sourcesafe worked up until the VS 2005 release.

  • (cs)

    Hmm... where does SQL Server store its data?  Where does Oracle store its data?  I thought the existence of the Ether was disproven almost a century ago, and yet modern RDBMS's seem to be storing their data there...

    Oh no, wait, they store it ON THE FILE SYSTEM!  Wow, revelation!

    I say we blame the OS vendors for this whole quagmire... obviously, if they had written better-performing disk IO code, this never would have been an issue.

    (Sorry, forgot to wrap that all in <sarcasm> tags)

  • cvi (unregistered) in reply to ParkinT

    Apparently problems with card-scanner-systems are kinda common. "My" uni had one building all students (some odd 11000) were supposed to have access to. The system was unable to handle that amount of people (in a single node/scanner?).

    Anyway, the problem was resolved by only giving students with "special reasons" access. (The doors were open daytime, though).

  • (cs) in reply to filesalot
    Anonymous:

    You can go pretty far with a directory tree (it is a tree index, after all) as long as you keep the size of the directories small.

    Well, that's the key.  Small directories.  That's why this system worked at first, then started slowing down as the directories grew larger.  Nobody saw that they had a bad design until it was too late.

    Directories with >10,000 files in them are slow because they are usually stored unsorted, and must be searched linearly.

    Putting the data into a DBMS makes it easy to keep the data sorted.  All you have to do is add an index and you'll be able to handle a lot more data, without having to resort to tricks to keep your directories small.

  • (cs)

    The best part was making the users swipe all of the readers with punch-cards.  Who needs these fancy whatsits with the magneto thingies.  That is sooo 1950's.

  • Runtime Error (unregistered) in reply to Roger
    Anonymous:

    Alex Papadimoulis:
    For being all computerized, it worked slowly, taking about a second or two per scan. When used at student events, it would take 3-5 seconds per scan, if it worked at all. This was a bit of an issue.

    I am almost certain that the clients never specified the response time in the original specifications.

    Poor specifications == poor product == client's fault.



    So you are saying that the client has to specify that the vendor has to build something that "isn't retarded" in the specifications? 


  • Another Moose (unregistered) in reply to Roger

    Anonymous:

    I am almost certain that the clients never specified the response time in the original specifications.

    Poor specifications == poor product == client's fault.


    The customer's job is to tell us what they need.
    Our job is to work out how to give them something that will actually do what's necessary.
    We write the specifications. We create the product. If the product makes the customer unhappy then it's our fault because our job isn't to do the bare minimum we can get away with.

    If the customers don't know that they need to decide on an acceptable minimum response time, then a responsible professional would tell them so.

  • [Si]dragon (unregistered) in reply to Pastor_Of_Muppets
    Pastor_Of_Muppets:
    s/it's/its


    Nah, you got it wrong.  An apostrophe token means "here comes an 's'!!"
  • Another Moose (unregistered) in reply to JS

    Anonymous:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?

    I want to be the one who has the greater take-home pay, with which to buy stuff for myself.

    The company that charged less probably also required less actual work in order to get the system up and running, which means lower overheads, and less income going on expenses. Revenue doesn't matter - the real question is who made more profit.

  • (cs) in reply to Roger
    Anonymous:

    Alex Papadimoulis:
    For being all computerized, it worked slowly, taking about a second or two per scan. When used at student events, it would take 3-5 seconds per scan, if it worked at all. This was a bit of an issue.

    I am almost certain that the clients never specified the response time in the original specifications.

    Poor specifications == poor product == client's fault.



    blaming the client for bad specs == making lame excuses == a really, really bad consultant


  • (cs) in reply to JS
    Anonymous:
    Which would you rather be: The company that got it right, or the company that made (I'm assuming) several times the money?


    I'd much rather be the company that got it right, as that may help to guarantee future contracts...
  • (cs) in reply to synesthetia
    synesthetia:
    I would hope it wasn't Purdue.  The students there could do 10X better than this.

    That is, however, exactly what this sounds like.  It sounds like the quality of work you would get with a mediocre school's senior project.


    Just don't expect them to know what "hexidecimal" is...
  • filesalot (unregistered) in reply to loneprogrammer

    Right, this should be in a DBMS no question.

    But it could have been designed so that the directories never had more than 100 entries in them, no tricks required, just more directories in the tree from the start.

  • (cs) in reply to loneprogrammer
    loneprogrammer:
    Anonymous:

    You can go pretty far with a directory tree (it is a tree index, after all) as long as you keep the size of the directories small.

    Well, that's the key.  Small directories.  That's why this system worked at first, then started slowing down as the directories grew larger.  Nobody saw that they had a bad design until it was too late.

    Directories with >10,000 files in them are slow because they are usually stored unsorted, and must be searched linearly.

    Putting the data into a DBMS makes it easy to keep the data sorted.  All you have to do is add an index and you'll be able to handle a lot more data, without having to resort to tricks to keep your directories small.



    Well, to reduce the number of files in each door directory, they should have put all the valid IDs into a text file, instead of one file for each student, and then used some sort of O(1) regex to search the text file! ;)
  • tim (unregistered)

    gotta love relational batch files, too

    some OS's slow down once you have a few thousand files in a single folder. I remember one system I saw with about 75000 files in a folder (again, a folder/file-based 'database') and that was slow to read or write, had file locking issues and generally got replaced as soon as humanly possible.

    the "xml->text->process->xml->text" is fancy :)

  • Woody (unregistered) in reply to Another Moose
    Anonymous:

    Anonymous:

    I am almost certain that the clients never specified the response time in the original specifications.

    Poor specifications == poor product == client's fault.


    The customer's job is to tell us what they need.
    Our job is to work out how to give them something that will actually do what's necessary.
    We write the specifications. We create the product. If the product makes the customer unhappy then it's our fault because our job isn't to do the bare minimum we can get away with.

    If the customers don't know that they need to decide on an acceptable minimum response time, then a responsible professional would tell them so.



    It's amazing howoften marketing doesn't understand that.  And that Engineering really needs to treat marketing like that.

    "Yes, I hear you say you want X.  What that actually means is that you want Y.  Trust me on this."

    They seem to hate it when they remember that you know more about writing code/designing systems than them.
  • (cs) in reply to ParkinT

    ParkinT:
    Overall the University would have been better off if they let the students write the system.  Make a part of large project in a software development or engineering class!

    Right.... that would be great, each student on the project would have their own backdoor/easteregg/prank on the system. it may run faster, better, etc, but it'd be worthless as far as the programmers, their friends, their friends friends, the girl in the next dorm... etc

    Yah... that'd be great....

    Erik of Ekedahl

  • Derek (unregistered) in reply to chaim79
    chaim79:
    ParkinT:
    Overall the University would have been better off if they let the students write the system.  Make a part of large project in a software development or engineering class!

    Right.... that would be great, each student on the project would have their own backdoor/easteregg/prank on the system. it may run faster, better, etc, but it'd be worthless as far as the programmers, their friends, their friends friends, the girl in the next dorm... etc

    Yah... that'd be great....

    Erik of Ekedahl

    I studied at FSU in Jena, Germany for a semester a couple of years ago.  They actually did have their own chipcard system produced by their CS dept.  They had a few professors in charge of the thing, but the bulk of it (as I understand) was written by students.  It worked great.  It was deployed across the campus, and I never had any problems, nor heard of anyone who did.

    Backdoors/easter eggs/etc?  Do you really think that anyone would be foolish enough to take code from random students and put it in a production system without checking it first?  Besides, you'd presumably only allow students to work on it that 1) you trust and 2) understand that inserting a backdoor into real software is typically illegal.  Illegal electronic entry, criminal negligence, etc.

Leave a comment on “We Don't Need No Stinkin' Database”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article