• WonderingAbout (unregistered)

    Why were the 500-per-day trucks only delivering 300 or so crates?

  • Mark (unregistered) in reply to Yesinouhehe
    Yesinouhehe:
    Is everything you read on the internet true?

    What if: Access was grandfathered in from some rinky dink outfit and Access were only a front end to MSSQL and one application of many in the system and Eric is not a developer but just a poor smuck clerk and Eric hacked Access to get to the data in the first place & Access had nothing to do with the previous big $$$ loss...

    Still no excuse for a p*ss poor system but change 'barely' accessible to 'easily' accessible and 'developer' to 'hacker' to inject some reality.

    "Is everything you read on the internet true? "

    In this case, yes. Maybe not to the same level of scale, but generally the WTFs on this are all believable. How much corporate IT experience do you have? There are plenty of us here who've lived these scenarios. Maybe not as extreme, but the general stories have happened to us all.

  • Jethris (unregistered) in reply to Mark
    Mark:
    Walleye:
    tekiegreg:
    First thing I'm doing if I get there is upsizing to SQL Server and let access run as the front end only (One of it's redeeming features is access functions well as a front end for SQL Server, can preserve the existing access app but have a more robust database behind it).

    This solution always sounds good, until you realize that there will now be lots of brand-new and unhandled exceptions in your production system.

    Can someone say "ODBC Error"? Access front end runs this:

    DoCMD.RunSQL "Update table set field = value"

    And it runs it on a linked SQL Server table the user doesn't have UPDATE privileges on. Good luck trapping that.

    OTOH, I agree. Generally, Access does make an easy to develop front-end to SQL Server. You just have to know its limits.

    You get a generic error. But, I'd never use DoCmd.RunSQL against a SQL Server database. Instead, I'd use ADO and pass in a connection string. Much less overhead.

    CAPTCHA appellatio. Is that a kind of ice cream, or an sexual act?

  • (cs) in reply to MET
    MET:
    You had me* at "Microsoft Access"

    *Laughing out loud

    Hell yes. At that point, I was fully expecting that to be story 1 of 3. BUT NO, IT JUST KEPT ON GOING.

  • (cs)

    lol, deju vu

  • (cs)

    I literally gasped when I read "Microsoft Access"!

  • Franz Kafka (unregistered) in reply to Bob X
    Bob X:
    Dude, haven't you noticed how many WTFs are the direct result of choosing MS Access to be the backend of a high-volume multi-user production-critical application like this?

    Frankly, MS should limit Access to 50 tables per DB, 100k records per table, and 20 concurrent users. That would make it great platform for your tape collection DB, but impossible to use for Ford's production control system. As it should be.

    Captcha: luptatum. WTF?

    That's fucking stupid. In the situation you want to avoid, they'll cobble something together, grow the tables over time, and run into a hard wall at some random time, probably at 11:30 on a tuesday with no way out except to upgrade the system while completely dead in the water.

    You're basically advocating a time bomb.

  • (cs) in reply to Stan
    Stan:
    Haw! It HAD to be one of the US big-three. No other automaker is that stupid!
    Knowing someone who works at one of the Big-Three, I have to agree with that. Many internal software stuff runs on WTF-worthy systems because management doesn't give 'em the right tools.

    I'm just grateful I didn't apply for that position...

  • Franz Kafka (unregistered) in reply to Walleye
    Walleye:
    tekiegreg:
    First thing I'm doing if I get there is upsizing to SQL Server and let access run as the front end only (One of it's redeeming features is access functions well as a front end for SQL Server, can preserve the existing access app but have a more robust database behind it).

    This solution always sounds good, until you realize that there will now be lots of brand-new and unhandled exceptions in your production system.

    I for one like it. Of course, you'd need this thing called QA and testing. If you can capture a day's worth of traffic and run it through the new system without errors, I'd call it good.

  • (cs) in reply to Bob X
    Bob X:
    Believe it. I work for a major semicon, and our worldwide production control system still runs on a VAX. I poop you not.
    \

    And how many attempts were made to replace it?

  • (cs) in reply to AMerrickanGirl
    AMerrickanGirl:
    Why Oracle? Why not SQL Server? You're already in a Microsoft environment.

    When all you have is a hammer, everything looks like a nail.

    You'd be surprised at how many people think "database" is synonymous with "oracle". Fortunately, I'm no longer employed by such types, nor will I ever again be.

  • Franz Kafka (unregistered) in reply to wee
    wee:
    AMerrickanGirl:
    Why Oracle? Why not SQL Server? You're already in a Microsoft environment.

    When all you have is a hammer, everything looks like a nail.

    You'd be surprised at how many people think "database" is synonymous with "oracle". Fortunately, I'm no longer employed by such types, nor will I ever again be.

    As a linux/oracle bigot, I'd be using SQL server too. Of course, my own projects run postgres, since they're small and I can't afford licensing Oracle.

  • (cs) in reply to d000hg
    d000hg:
    Getmeaguiness:
    Makes you wonder how MSAccess got to be the platform of choice
    Probably they knocked up a working prototype, and got trapped by it?
    I'm pretty sure that is what happened at the company I was previously employed with. The app was a bunch of different 3rd party components (AvantGo, for example) glued together with some C++ code and JavaScript. And by C++ code, I mean there were about 3 classes and each one contained about three or four hundred functions. But it worked enough to impress the sales drones.

    So, they started selling it, figuring they could just tweak what needed tweaking to get it working for the customers. Of course, this didn't work out that well, and seemingly simple tasks took weeks to implement.

  • Mark (unregistered) in reply to Jethris
    Jethris:
    Mark:
    Walleye:
    tekiegreg:
    First thing I'm doing if I get there is upsizing to SQL Server and let access run as the front end only (One of it's redeeming features is access functions well as a front end for SQL Server, can preserve the existing access app but have a more robust database behind it).

    This solution always sounds good, until you realize that there will now be lots of brand-new and unhandled exceptions in your production system.

    Can someone say "ODBC Error"? Access front end runs this:

    DoCMD.RunSQL "Update table set field = value"

    And it runs it on a linked SQL Server table the user doesn't have UPDATE privileges on. Good luck trapping that.

    OTOH, I agree. Generally, Access does make an easy to develop front-end to SQL Server. You just have to know its limits.

    You get a generic error. But, I'd never use DoCmd.RunSQL against a SQL Server database. Instead, I'd use ADO and pass in a connection string. Much less overhead.

    CAPTCHA appellatio. Is that a kind of ice cream, or an sexual act?

    No, you get an ODBC error. I have a directory full of screenshots of them. Maybe it depends on the setup?

    And yes, using ADO to execute stored procs is the better solution. But before you get that far you sometimes just need to hack something together to see if it works.

  • Khazwossname (unregistered) in reply to wee

    Could be worse. Where I work I keep encountering people (usually clients) who think "database" is synonymous with "Excel".

  • Mr. (unregistered) in reply to WonderingAbout
    WonderingAbout:
    Why were the 500-per-day trucks only delivering 300 or so crates?

    Perhaps the 300 crates were outgoing crates. They probably had trucks for incoming crates as well ;-)

  • James (unregistered) in reply to Paul Keeble
    Paul Keeble:
    It held all complaints made against them and did the workflow on resolution of the compliants.

    The moral of this story is that you CAN run a mission critical system on MS Access and while as "real" developers we scoff at everything at this approach MS Access is actually working! That is more than I can say for some Java/C#/whatever apps I have seen.

    The actual moral of this story is that you can run mission-critical apps on Access if you define "mission critical" loosely enough. It's a pretty special case -- you lose data from your "complaint system" and what does it do? Generate more complaints -- that just get lost the next time somebody hoses the system!

  • (cs) in reply to Pecos Bill
    Pecos Bill:
    I literally gasped when I read "Microsoft Access"!

    I used to work for the CS department of a very large university. They had students get involved in technology some time in the late 90's by involving them in creating a new online application system. Instead of people mailing in an app to attend the university's CS dept, they could go online and do it. Makes perfect sense, right? Especially for a CS department; it's good that they're "high tech". Now think about who was building this: students with very little real world experience and prima donna, knowitall professors with about the same level of actual, practical experience in designing non-theoretical systems.

    I won't bore you with all the details, but suffice to say that it used cold fusion, MS Access, C, C++, bash scripting, a procmail recipe and Excel. I recall thinking that an OCR system would have fit right in. Later, they in fact added an OCR system for scanning in non-US applications.

    When I first got there, I was given the task of "modernizing" the app system, since it would occasionally drop applications in the ether, submit them twice, deny some, etc. Off by one errors, stupendously horrible coding, no source control, etc. You should have seen the C app that was used to draw a calendar for the web form (yeah, that's all it did was basically print the output /usr/bin/cal). It had the days of the month, for each month, stored in arrays. It was Y2K compliant, but didn't particularly care about leap years. I think it would have stopped running in 2010, since the years were hard-coded as well.

    The front end parts had some templates, but apparently the developers got tired halfway through and stopped any type of abstraction. Content and logic might commingle, or they might not. It depended on who wrote that particular bit of code, how late in the day it was, how late in the semester it was, etc. They told me it took almost a year to get it finished, so you'd see whole huge swaths of code copied and pasted into the same file, with slightly changed function names. Some new student would take over and it seemed like someone recommended the "copy, paste and rename" style of maintanence. Code reuse, in a similar vein, was mostly copy/paste. Global variables where everywhere, lots of magic numbers, etc. There were far more files in place than were needed, and it took some doing to figure out what was actually being run.

    The only language that was approved on the new web servers was PHP, so I rewrote it in that, and stored everything in the MySQL DB they had running for other purposes on a newer Linux server (which was actually racked up and backed up). I'm thinking it came in at about 500 lines of code and took a day and a half to write and test. The admin clerk ladies couldn't be asked to learn anything new, so I wrote a nightly job that would go through the day's apps, write out an excel sheet for each one, then mail it to the people who were supposed to enter it all into the school's main system (which was backed by an old DB2 system that was impossible to get access to).

    That's just one example. One of the profs there was a huge MS fan (I think he had some research sponsored by them or something), so Access was all over the place. The room reservation system ran off an Access DB on one of the admin clerk's desktop PCs, for example. I think each meeting and class room had it's own table. I remember that there were a shitload of them, anyway. The class scheduling system ran on another clerk's PC. Hooray distributed computing.

    All in all it was pretty pathetic. I thought working for the CS dept of a university would be a great learning experience. Mostly I learned to hate MS Access.

  • Corazu (unregistered) in reply to Tony
    Tony:
    Anonymous:
    Some parts of Google (acquired parts) actually do use MS SQL Server, but they try not to do that for too long.

    I dislike MS products just as much as the next guy, but it seems Google's taken "embrace and extend" and turned it into "assimilate and rewrite," which is a WTF unto itself.

    I don't think this is really a WTF. They have a platform that they work with and want new products that they will be maintaining to run on the same platform. There's nothing wrong with that, it's smart. Theoretically easier to maintain.

  • (cs) in reply to d000hg
    d000hg:
    Getmeaguiness:
    Makes you wonder how MSAccess got to be the platform of choice
    Probably they knocked up a working prototype, and got trapped by it?

    Nah. Port the backend tables to a MSSQL system (which is trivial...they make it REAL easy to upgrade), and then just link them back to the Access frontend. You gain the sort of performance a real RDMS can offer, for very minimal work and chances are the people who work with the system daily won't notice any difference.

    Then when you've got a stable scalable backend, you can work on putting together a real application.

  • (cs) in reply to Pecos Bill
    Pecos Bill:
    Bob X:
    Believe it. I work for a major semicon, and our worldwide production control system still runs on a VAX. I poop you not.
    \

    And how many attempts were made to replace it?

    None. Duh. Truly critical systems will stay decades behind the curve for upgrades because the consequences of a failed migration are literally impossible to calculate.

  • Ben4jammin (unregistered)
    This can't be real. He never mentions near-daily recovery of the database when Access inevitably corrupts the MDB.
    My first encounter with Access in production included more than daily recovery...at least 2-3 times per day. A private 2-year college was using it for student records, etc. I worked for the company that bought them and the first thing I was shown was how to recover it, since that had to be done on a daily basis. I hated that fricking thing...I refuse to call it a "database".
  • (cs) in reply to Corazu
    Corazu:
    Tony:
    I dislike MS products just as much as the next guy, but it seems Google's taken "embrace and extend" and turned it into "assimilate and rewrite," which is a WTF unto itself.

    I don't think this is really a WTF. They have a platform that they work with and want new products that they will be maintaining to run on the same platform. There's nothing wrong with that, it's smart. Theoretically easier to maintain.

    It isn't a WTF at all. The clustering and monitoring software is such that it's a huge effort to maintain uptime on anything but the stuff built in-house. Hell, you can't even run a binary on the clusters unless it's written in C++, Java or Python. Stuff runs really well, and there's all sorts of mechanisms for making sure things run smoothly. But to get at all that great stuff, you have to leverage the in-house work.

    It's acquisitions that bring in SQL Server and the like. They put them in a jailed environment, assign them a couple sysadmin types to watch over everything, and then have the newly-acquired leaders come up with a migration plan (while the developers scramble around like mad trying to learn all the googley tech needed to actually do the migration).

    At least, that's how we did it when I was there.

  • Robin Goodfellow (unregistered) in reply to Cybercat
    Cybercat:
    The real WTF:

    If the company who programmed this monstrosity could foot a random $285,000 bill, why didn't they put in enough money for a new programming team to write a new application that wasn't such a pile of shit? $285k is enough for one good senior level programmer and 3-4 average to newbie levels for drone work. Problem solved?

    The problem is not just the cost to build a better system. The problem is in making the transition. The replacement has to be able to come on line and work at 100% capacity from day 1, with very little down time. And downtime while switching systems runs at $300k per hour. While the amount of engineering it takes to make a better system may be relatively small, the amount of engineering necessary to make a system that can be transitioned to smoothly with almost no downtime is much higher.

    Also consider that in their environment they are relatively clueless about software development and their guides tend to be questionably competent consultants with questionable ethics. They don't know how to get high quality software, all they know is how to get very expensive crap (as seen here and in many other examples). Thus, their perception is that the software quality needed for minimum downtime during deployment is either unattainable or would require an astronomical expenditure to acquire. And, of course, the cost of a system developed less expensively would be an extraordinarily high cost in downtime. Both of these perceived costs vastly exceed the ongoing cost of having a crappy system, so they stick with what they have.

    The devil you know vs. the devil you don't...

  • Thunder (unregistered) in reply to bobzilla
    bobzilla:
    Global Warmer:
    ...allot...
    Grammar Nazi Attack: allot? How about 'a lot'?
    Usage Nazi Attack: "Grammar Nazi"? How about "Spelling Nazi"?
  • Franz Kafka (unregistered) in reply to Robin Goodfellow
    Robin Goodfellow:
    Cybercat:
    The real WTF:

    If the company who programmed this monstrosity could foot a random $285,000 bill, why didn't they put in enough money for a new programming team to write a new application that wasn't such a pile of shit? $285k is enough for one good senior level programmer and 3-4 average to newbie levels for drone work. Problem solved?

    The problem is not just the cost to build a better system. The problem is in making the transition. The replacement has to be able to come on line and work at 100% capacity from day 1, with very little down time. And downtime while switching systems runs at $300k per hour. While the amount of engineering it takes to make a better system may be relatively small, the amount of engineering necessary to make a system that can be transitioned to smoothly with almost no downtime is much higher.

    This part is easy (but takes some time). What you do is this: set up a feature to mirror the daily traffic to the new system and some tools to verify that things are recorded correctly. Migrate the data to the new system every friday after hours and fix problems until the new system is more stable than the old one. Of course, a sql server migration is the sort of things that should be relatively low on the risk level - mostly making sure your access blob handles the new environment well.

  • notme (unregistered) in reply to biziclop
    biziclop:
    I keep thinking that if it wasn't software but forklifts or trucks in similar condition, nobody'd take the risk.

    Well, failing business software doesn't usually result in physical injuries or death...

  • Bob Healey (unregistered) in reply to Bob X

    Yeah, but at least the VAX was intended for that role, unlike Access. It might be 15-25 years old, but it was intended for large production systems.

  • Defenestrator (unregistered)

    Sure, MSSQL Server's a bit pricier, especially if you've already got Access, but what about MSDE/MSSQL Express? It seems like any time there's going to be more than one concurrent user, there's no reason to use Access over it as the back-end.

  • francisco (unregistered) in reply to Bob X
    Bob X:
    Believe it. I work for a major semicon, and our worldwide production control system still runs on a VAX. I poop you not.

    That's because it was pre-MS Access; developers knew how to code and manufacturers built things to last.

  • (cs) in reply to tekiegreg
    tekiegreg:
    It's locking structure is not at all suited for multi-user and it likes to acquire table locks for the simplest of things. And why not? As far as Access is concerned, there should maybe be 1 or 2 people in the db at one time...

    If it's only designed for 1 person...why have locks at all?

  • plaga (unregistered) in reply to Jethris
    Jethris:
    Access is a great tool (consider it a small hammer). It's great at hammering nails to hang pictures from, but you wouldn't want to use it to try and bust up concrete.

    I developed an Access app that managed mission critical tapes for a branch of the US Military. Granted, all it did was track the tapes (when they were being recorded, what satellite was operational, how long do they need to be kept, which tapes could be reformated, etc.), but it did those tasks very well.

    It had 1 data entry user, and 5-10 read-only users. Maybe 2 concurrent user, 3 tops.

    SQL Server would have been overkill. Access was cheap, fast, created nice reports, and fit the bill. Downtime for the app had very minimal costs.

    I love using Access for what it was designed for, a desktop database. But, for that many records? The lack of transaction logging itself would be scary.

    As they say, when all you have is a small hammer, every thing looks like a small nail...

    wait that didn't sound right...

  • JockTheKiwi (unregistered) in reply to Global Warmer

    This article was forwarded to me by a developer I am working with to point out that Access is not a "Real Database". He likes to point this out because I am a BA who has used Access to do a lot of work it probably should not have been used for.

    Thanks you oh nameless developer (Yes Steve I mean you) for taking the time to prove how inferior Access and I am to you and your l33t developer c# skills. I grovel at your feet.

    Because I am so petty and small minded and have to reply in some form I would just like to ask you if the development using MS Workflow Foundation is complete yet?

  • (cs) in reply to Stan
    Stan:
    Haw! It HAD to be one of the US big-three. No other automaker is that stupid!
    Well, a colleague of main worked for one of the German big-three on replacing a near-production system (meaning production could go on without it - for about 15 minutes) that consisted of a bunch of Korn shell scripts and a C GUI that only ran on a certain outdated version of HP Unix, which in turn did not run on current hardware. This mess had been gradually built over the years by a single employee, and he was the only person who understood it.
  • Franz Kafka (unregistered) in reply to brazzy
    brazzy:
    Stan:
    Haw! It HAD to be one of the US big-three. No other automaker is that stupid!
    Well, a colleague of main worked for one of the German big-three on replacing a near-production system (meaning production could go on without it - for about 15 minutes) that consisted of a bunch of Korn shell scripts and a C GUI that only ran on a certain outdated version of HP Unix, which in turn did not run on current hardware. This mess had been gradually built over the years by a single employee, and he was the only person who understood it.

    If it were a certain online bookseller, that lone developer left 3 years ago to do something else and nobody really knows what it does anymore.

    J/K: most of the really nasty stuff is either being replaced or noncritical.

  • foxyshadis (unregistered) in reply to Paul Keeble
    Paul Keeble:
    The morale of this story is that you CAN run a mission critical system on MS Access and while as "real" developers we scoff at everything at this approach MS Access is actually working! That is more than I can say for some Java/C#/whatever apps I have seen.
    This is what you call "working"? I'd hate to see what you call broken. Ouch.
    Franz Kafka:
    This part is easy (but takes some time). What you do is this: set up a feature to mirror the daily traffic to the new system and some tools to verify that things are recorded correctly. Migrate the data to the new system every friday after hours and fix problems until the new system is more stable than the old one. Of course, a sql server migration is the sort of things that should be relatively low on the risk level - mostly making sure your access blob handles the new environment well.
    There isn't always an "after hours", sounds like the case here, but they might be able to negotiate for a maintenance window in the dead of night on a weekend.

    There comes a time when the cost of the old is much greater than the total cost of the new. Big system developers will consistently underestimate that cost, while users and little system developers (Access & Excel, bash scripts) will consistently overestimate it.

    JockTheKiwi:
    This article was forwarded to me by a developer I am working with to point out that Access is not a "Real Database". He likes to point this out because I am a BA who has used Access to do a lot of work it probably should not have been used for.
    Tell the guy to do it for you, if he wants you to upgrade so bad. Maybe he will, maybe he'll piss off, maybe he'll learn it's not worth it, either way you win.
  • SomeCoder (unregistered) in reply to JockTheKiwi
    JockTheKiwi:
    This article was forwarded to me by a developer I am working with to point out that Access is not a "Real Database". He likes to point this out because I am a BA who has used Access to do a lot of work it probably should not have been used for.

    So we've probably seen your stuff on here before. Nice to see the source of a WTF comment on the forums :)

  • Access boy (unregistered)

    And here is what they say in the Access newsgroups:

    http://groups.google.com.au/group/microsoft.public.access/msg/ee0b87be45d1e61a

  • Moz (unregistered) in reply to Soviut
    Mr. Smith: When any company tells me they are using Access I tell them that my 8 yr old niece uses that as well for organizing her tape collection

    What are tapes? ;) (The real WTF?)

    The niece obviously has a rigorous backup schedule for the server in her wardrobe.

  • (cs)

    Even if the workstation hadn't gone a little haywire with its "security" trigger, didn't he know he was working with Access just by looking at it? Exporting a joined table with just 100,000 records from a network location can cause a machine freeze up for a good minute. Never mind that Access also sets up record and file locks frequently, for seemingly no good reason, no matter what settings you have in place.

    Thinking, okay, what could he have done instead ...

    • Copied the Access file itself to the workstation (I think the largest a file can get before records corrupt is something like five gigs)
    • Saved the table object as a copy within the application, then exported the copy
    • better yet, ask someone else what they did when they started, to get up to speed
  • KOkon (unregistered) in reply to Global Warmer
    They do not usually make you pay this up front, they usually deduct it from what they owe you over time. Also, you can usually negotiate it down.

    Same thing, you don't pay the programmers up front, and that number is just the start. You eventually will need to pay more within a year.

  • Anonymous Coward (unregistered)

    What scares ME the most is the idea of somebody jumping into my machine like that. I have this weird paranoid thing about my computer being MINE. I don't like for somebody to borrow it for 5 minutes to check their email. I don't like sharing my computer. To have somebody suddenly go remote access on me scares the crap out of me.

  • zompist (unregistered)

    Wait, 500 trucks a day come in and 200 leave? There's your problem... every day there's 300 trucks that will never leave!

  • more randomer than you (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    Pecos Bill:
    Bob X:
    Believe it. I work for a major semicon, and our worldwide production control system still runs on a VAX. I poop you not.
    \

    And how many attempts were made to replace it?

    None. Duh. Truly critical systems will stay decades behind the curve for upgrades because the consequences of a failed migration are literally impossible to calculate.

    you might like to reconsider your choice of the words "literally" and/or "impossible". "Literally" does not mean "almost/sometimes" and "impossible" does not mean "very hard"

  • (cs) in reply to Anonymous Coward
    Anonymous Coward:
    I have this weird paranoid thing about my computer being MINE.
    I've had this discussion several times, always in response to some IT policy like virus scanner or screen saver timeout. My response has been to quiety remind the person, "No, that is *not* your computer, it is your employer's. They paid for it. They are paying for the electricity powering it. They are paying for the internet traffic. They are paying for your time. If they want to mandate what desktop and colour scheme you get and what virus scanner you run, they are perfectly within their rights."

    As to the original post, every horrible, sweat-inducing, heart-pounding, lying-awake-in-bed dreading-going-in-to-work-tomorrow job I've had has involved Microsoft Access. Don't get me wrong, I like the product and have had some great jobs developing in it. What I hate is the fact that it it has nothing to stop you building pure bantha pudu.

    B

  • more randomer than you (unregistered)
    FTM:
    As it turned out, that wasn't such a good idea. After a few minutes of watching the "Exporting Table ..." dialog, Eric's screen flashed and a lock icon appeared in the upper-right corner. Windows Task Manager opened up and, unable to move the cursor himself, Eric watched the ghost in his machine click on one program after another, terminating each one.

    Shortly thereafter, Notepad opened up and the following came in, letter after letter:

    DO NOT DO WHATEVER YOU WERE DOING!! YOU DEADLOCKED -- MCL CRASHED!!!!!

    • THANK YOU, IT/MCL SUPPORT

    Oh I get it. This happened before telephones were invented.

  • Steve (unregistered) in reply to JockTheKiwi

    Suck my balls. If you're specifications for the MS workflow Foundation were done properly I wouldn't be trying to force a square peg into a round hole and taking so much time developing this.

    Fag.

  • Steve (unregistered) in reply to JockTheKiwi

    Suck my balls. If you're specifications for the MS workflow Foundation were done properly I wouldn't be trying to force a square peg into a round hole and taking so much time developing this.

    F@g.

  • (cs) in reply to Steve
    Suck my balls. If your specifications for the MS workflow Foundation were done properly I wouldn't be trying to force a square peg into a round hole and taking so much time developing this.

    F@g.

    A square peg fits into a round hole if the hole is big enough.

  • Rand (unregistered) in reply to havokk
    havokk:
    "No, that is *not* your computer, it is your employer's. They paid for it. They are paying for the electricity powering it. They are paying for the internet traffic. They are paying for your time. If they want to mandate what desktop and colour scheme you get and what virus scanner you run, they are perfectly within their rights."

    Hey, I just had a great idea, I should give my girlfriend a cheap computer. Then I can install a keystroke logger and see if she's doing anything I don't approve of, and make her use a picture of us as a desktop background. I guess that's perfectly acceptable, since I paid for the computer...

Leave a comment on “A Barely Accessible System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article