• (cs)

    Several people seem to be under the misconception that an inefficient method of returning a Boolean value is the main WTF with this piece of code. It isn't (though it is the hardest to understand why the coder thought it would be a good idea).

    The main WTF is that instead of using Excel's built-in function to count the number of non-blank cells in a given range, the code loops through each cell, does a text replacement on the contents to remove manual line breaks, and checks to see if the result is empty.

    A subsidiary WTF is that if a non-empty cell is found, the code continues to loop through all the remaining cells in the row, rather than ending the loop at that point.

    Using an extra, unnecessary Boolean to store the result before assigning it to the function (inefficiently) and clearing the local variables before the end of the function are minor WTFs - it is stupid code but it's not going to hurt the performance.

    Salami:
    To me, the analogy is that there is no truck, but a bunch of people having to carry the freight on their back. An enterprising person comes along and cobbles together a cart, which makes things a lot easier. Then you come along, see the cart, and starts nitpicking that the cart squeaks when it moves and doesn't turn very well.
    No, it's more like the Futurama episode "Mother's Day": "Wouldn't it work better if the wheels were round?"
  • Herby (unregistered) in reply to lolwtf
    lolwtf:
    It's C-Tic-Tac-Toe.

    ...

    Just remember that a chicken can be trained to play this game and win (usually against drunk bar patrons). I tend to think that not much has improved in Microsoft's version, still a "chicken language".

  • Niels (unregistered) in reply to Josh

    Python's plethora of 'slick' language features is what design patterns are for Java programmers - a great way to over engineer and over complicate.

    There's shitloads of crappy python code out there, and there will be more as soon as self-taught hobbyists everywhere are discovering the language.

  • (cs) in reply to Doodle
    Doodle:
    Lots of Creative people here today!

    One comes up with the worlds greatest analogy, the other shoots down with world's greatest response... And all over something that don't matter for naught.

    love the four mile long posts too, people. Wish they actually said something, though.

    Blah!

    Lemme try.

    Last year I did about 3 weeks of consultancy for the same company as in the OP. From what I understood is that it takes a huge effort to convince IT to write an application for you. Because of the very rigid and procedural environment, they require a shit-load of documents, budgets approved, resources assigned and of course they need to get the right prioritization. If your problem isn't critical enough, it will never get placed on the road-map and you will never get past the first stage. So why bother writing up all documents for the pre-business case, business case, high level functional design, risk evaluation... ?

    Even if they would get a project, it would take a very long time to get it launched into production. Letting the local VB6 hobbyist write some small programs at least produces solutions with immediate impact on the problems that HR faced. Also HR will know that hiring consultants is way easier than trying to hire an internal developer, because that internal developer would just get placed in the IT department (not in HR) so this will get them nowhere.

    BTW, the code produced by their IT department is not really top notch. Because the name of the company is in the open now, it's probably not a good idea to go into details about this, but I might post it anonymized in the sidebar

  • Mike5 (unregistered) in reply to configurator
    configurator:
    private bool Row_Is_Empty(long iRowNr, object lLastCol, Worksheet sh)
    {...}
    

    Autocoverted with a tool

    I like how this tool claims that the result is production-quality. Simply because it's C#? Come on...

    Mike5

  • NH (unregistered) in reply to MisterCheese
    MisterCheese:
    Thought it was C-pound?

    C-hash of course - you have to smoke something to be able to use it! :-p

  • NH (unregistered) in reply to CodeReview
    CodeReview:
    Code Dependent:
    Voodoo Coder:
    Here's a 3 line solution that checks the first row:

    If WorksheetFunction.CountA(Range("1:1")) = 0 Then

     rowIsEmpty = True
    

    End If

    Why even bother with the If statement?

    rowIsEmpty = (WorksheetFunction.CountA(Range("1:1")) = 0)

    god damn we see this all the time in code reviews... bool returnVal; if (expression == true) { returnVal = true; } else { returnVal = false; } return returnVal;

    can we all just agree that return (expression == true); does the same thing and stop fucking around?

    Even optimize it as:

    return (expression);

  • NH (unregistered) in reply to Anonym
    Anonym:
    Josh:
    Wyrd:
    ...but the hype always said that Python makes programming easy, so maybe it's harder to *accidentally* produce bad code in it?

    You know, that's one thing I've never seen: a Python WTF. Anyone care to share? I'd pony up a $10 reward for Python WTF's but I'm too cheap.

    I'd like to see a real assembler WTF.

    Be careful what you wish for.

    I suspect that you can get a lot of interesting examples from disassembling early computer virus code - especially the ones that obfuscated themselves.

    And I also suspect that there have been programmers that have made "invalid" jumps into the code to obtain the wanted result with the least amount of code. Not that unheard of in the early ages when the clock frequency was similar on all machines and a time delay was wanted. Worked fine until the hardware was upgraded.

    Even code that was designed with a specific version of the processor has been seen - like the classic Z80 CPU had a few "undocumented" operations, and if you installed a clone processor they weren't there. And some programmers did utilize these instructions to create more efficient code which caused problems in some cases.

  • Fred (unregistered) in reply to Scarlet Manuka
    Scarlet Manuka:
    Salami:
    To me, the analogy is that there is no truck, but a bunch of people having to carry the freight on their back. An enterprising person comes along and cobbles together a cart, which makes things a lot easier. Then you come along, see the cart, and starts nitpicking that the cart squeaks when it moves and doesn't turn very well.
    No, it's more like the Futurama episode "Mother's Day": "Wouldn't it work better if the wheels were round?"

    So I guess your point is, spending 3 days doing this is really no better than spending 3 weeks? Talk to me again after you've seen this process done by a secretary with a typewriter.

  • Fred (unregistered) in reply to chrismcb
    chrismcb:
    Procedural:
    Give them the credit they are due.

    Well if we have to give them the credit they are due, we can surely laugh at the bad code they write.

    Especially when they put things like "teller = tellher" into an interpreted language.

    It's not an interpreted language. VBS is interpreted. ASP Classic is interpreted. Excel VBA is compiled to a byte code machine, like Java or Python.

    Can we laugh now?

  • Fred (unregistered) in reply to Alexis de Torquemada
    Alexis de Torquemada:
    Every CS student would have written better code for a tenth of the money, though. And if Rob had really been worth his money, he would have given that student an internship.

    You work where mid level managers can casually offer internships?

  • Fred (unregistered) in reply to lolwtf
    lolwtf:
    It's C-Tic-Tac-Toe.

    Also: "every month... This song and dance took 2 people a week to accomplish. [...] then go to step 1 and repeat the process for the "final" version." You call it a WTF, I call it job security.

    I call it a process that would of, or did, take 3 weeks out of a month to complete before it was automated.

  • Piercy (unregistered) in reply to configurator
    configurator:
    [code] private bool Row_Is_Empty(long iRowNr, object lLastCol, Worksheet sh) { bool tempRow_Is_Empty = false; int j = 0; bool is_empty = false; int teller = 0; *snip*

    Autocoverted with a tool

    this the one i use, find it nice and helpful :) http://www.developerfusion.com/tools/convert/vb-to-csharp/

  • Dutch (unregistered) in reply to Sprite_tm

    Dutch people don't make mistakes

  • Waffle (unregistered) in reply to Dutch
    Dutch:
    Dutch people don't make mistakes

    Belgian ones do. Just look at the politicians.

  • Jesper (unregistered)

    Note that the word "teller" is Dutch for "counter".

  • (cs)

    Non-IT people accept solutions like this because it still justifies their existence. Who cares if a fully-automated solution could complete this in 5 minutes? At least they're needed 3 days out of the month! And they actually get some "down" time, unlike the old way of doing it where they worked 60-hour weeks for the whole month to get it done.

    For those who don't (or don't care to) read VB, the basic WTFs in the code are:

    1. Iterates over all cells in the row, even if we've already found the answer. If I have to check 10000 items to see if any meet a criteria, and the first one does, why check the remaining 9999?
    2. Uses an overly-convoluted mechanism to set an unnecessary temporary result variable.
    3. Resets a local variable (twice) for no reason whatsoever.
    4. Uses the same overly-convoluted mechanism to set the final result.
    5. Duplicates (badly) a built-in function.
  • IHasYerCheezburger (unregistered) in reply to mbv
    mbv:
    Rockafellow:
    Sprite_tm:
    Perhaps the guy is Dutch? Dutch 'teller' is English 'counter'.
    The variable name is not the WTF. The WTF is the clunky, unwieldy, implementation that includes redundant operations. Much easier would have been to declare a range and then:
    RangeIsEmpty = (WorksheetFunction.CountA(SourceRange) = 0)
    Courtesy ewbi.develops via Google.
    Well, it limits the number of companies that can be mentioned here to 5, and I've heard a similar story for a Dutch bank. They used Access for a database, which grew too big, so performance got rather slow. Someone I know was involved in their upgrade to some standard software (probably SAP).

    Dutch OR Belgium. KBC: 57000 employees (2007) Fortis: 56866 employees (2006, before the 2008 acquisition of ABN AMRO followed by the breakup and takeover by BNP Paribas)

    My guess is that it's KBC. I have some friends&family who work or worked there. I could ask someone to verify this story.

  • Anonymous (unregistered) in reply to GalacticCowboy
    GalacticCowboy:
    Non-IT people accept solutions like this because it still justifies their existence. Who cares if a fully-automated solution could complete this in 5 minutes? At least they're needed 3 days out of the month! And they actually get some "down" time, unlike the old way of doing it where they worked 60-hour weeks for the whole month to get it done.

    For those who don't (or don't care to) read VB, the basic WTFs in the code are:

    1. Iterates over all cells in the row, even if we've already found the answer. If I have to check 10000 items to see if any meet a criteria, and the first one does, why check the remaining 9999?
    2. Uses an overly-convoluted mechanism to set an unnecessary temporary result variable.
    3. Resets a local variable (twice) for no reason whatsoever.
    4. Uses the same overly-convoluted mechanism to set the final result.
    5. Duplicates (badly) a built-in function.

    Golly, gee whiz... Thanks for the lesson. I'm glad someone finally came along to explain the WTFs in this code. Here I was all confused and thought that it was obfuscated source code. Turns out it's actually VB code and I didn't know how to read it.

  • (cs) in reply to Salami
    Salami:
    Meh:
    Salami:
    Voodoo Coder:
    Alexis de Torquemada:
    Procedural:
    <snip>
    <snip>
    <snip>
    <snip> To me, the analogy is that there is no truck, but a bunch of people having to carry the freight on their back. An enterprising person comes along and cobbles together a cart, which makes things a lot easier. Then you come along, see the cart, and starts nitpicking that the cart squeaks when it moves and doesn't turn very well.

    Wow, this one really fired everyone up...

    My original point is this: There is a lot of incompetence in our field (duh...). Enough that we don't need people from outside the field bringing more of it in.

    To those who said I understated the value of hobby programmers: No, I did not. You transposed "hobby programmer" with "junior programmer" in your head. Yeah, we need people to write the small jobs, and they are those who are working professionally, gaining experience. What we do not need is a power user who are learning to code by reading what the Macro Recorder in Excel spits out. I know a LOT of great programmers started out as hobbyists. But if you don't have a fundamental understanding of programming, you have no business writing production code.

    And to the comment about Excel providing a valid solution to some problems, sure. Right after I made the comment that I hadn't written VBA in years, I received a request to add a function to a spreadsheet template that would check an account number across a database. For that, it worked. Did I use Excel to input information into the database? Frick no, I'm a professional for chrissake. Small, rudimentary functions serve a purpose in an Excel spreadsheet (beyond what it is already capable of doing). If you are writing large solutions to real problems in Excel, you're in the wrong field, or your company has wildly unrealistic expectations of what Excel can do.

    Finally, which analogy works best? None of em. We're programmers. I said surgeon because it was the first thing that came to my head. Surgeons work in a REAL time crunch, and they often don't get second chances (we just hit "compile" and fix what's broke). A mechanic fixes an existing problem, not engineers a new one...although it is closer when you consider whether you want an experienced mechanic or a hack fixing your breaks.

    The cart loader is interesting. It brings up a valid point...some people are OK with "It works". Me, not so much. If this guy built a cart, it would be a box with one dowel rod axel, one made of taped together paper towel rolls, three wheels (one of which is a hardened jelly donut), and it would never make right turns. Could you load a truck with it? Sure.

    But when management comes down and asks for a simple upgrade, say, a bigger box on the cart...upgrading becomes fixing, which becomes replacing. With the RIGHT solution.

    Economics 101: How much did the RIGHT solution COST. Not the set cost, the Economics cost. Start adding things up...like, the cost of the first cart...the development of the monstrosity...the labor involved in keeping it operational, then trying to upgrade it, fixing it...then, realize that management, at this point, is invested in the pot. They will bring in a pro now, but they will tell the pro to fix the abomination that they have. After a minimum month of paying the pro, they MIGHT find out that there jelly donut cart was a waste of money to begin with, and start on a real solution.

    So please, don't tell me that employing hack programmers is better than none at all. For the record, I've been the hack programmer. I look back on the train wrecks I've created and shudder. And I also think "Man was I a jerk for thinking that I was a programmer..."

    Be proud of what you do, and get pissed when someone tries to trivialize it.

  • (cs) in reply to NH
    NH:
    And I also suspect that there have been programmers that have made "invalid" jumps into the code to obtain the wanted result with the least amount of code. Not that unheard of in the early ages when the clock frequency was similar on all machines and a time delay was wanted. Worked fine until the hardware was upgraded.

    'Sright. A clbuttic example was "Centipede" on 8086 machines. Then Amstrad came along with their whizz-bang 8MHz CPU and you needed Jedi reflexes to play it on the easiest setting. So a little TSR COM was written and included on most coverdiscs to "slow" the box down by grabbing slices of CPU time...

  • (cs) in reply to MrBester
    MrBester:
    'Sright. A clbuttic example was "Centipede" on 8086 machines. Then Amstrad came along with their whizz-bang 8MHz CPU and you needed Jedi reflexes to play it on the easiest setting. So a little TSR COM was written and included on most coverdiscs to "slow" the box down by grabbing slices of CPU time...
    Followed by the classic Turbo button on so many PCs of the following generation.

    (For those that never envcountered one, it didn't speed the machine up when pressed, it slowed the machine down when released. But you can't label a button 'slow down' when you can label it 'speed up' instead.)

  • anon (unregistered)

    Not suprising at all. Some time ago i worked at one of the major retail sellers here. They would do HR tasks in Excel. For the other department, i had to program Excel spreadsheet, that would grab data from tables prepared weekly by SP on SQLserver, then they would edit data in excel, and submit it back. And that kinda tool for supply chain management. Some reporting was done via Excel too, until they reimplemented it via SSRS. As for this tool, row count was ~10.000. Other reports were generated from tables with ~600.000 rows(via excel pivots)

  • Yann (unregistered) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    How about the language's explicit self? It's easy to implement implicit self without surprises, but the authors of Python are so used to it that they no longer even see its ugliness.
    Yes, that is quite ugly. It relates to how dynamic the language is - which makes it fairly inobvious. Basically, any function you shove into a class becomes a method:
    class Foo: pass
    def function(self, str): print "String is:", str
    Foo.method=function
    This monstrosity turns a function into a method, which acts much the same except it requires the (unused) self argument to be a foo object. Any foo object also inherits it, but in them, the method is bound. It's quite possible, but strange and wasteful, to do aFoo.__class__.method(aFoo) instead of aFoo.method().

    Back to the point: Yes, Python allows plenty of WTFs. It's just sometimes more obvious when your code is NOT a WTF, and requires some experience to spout WTFs regularly.

  • (cs) in reply to nobuddy
    nobuddy:
    DaveK:
    I had another one that I can't quite remember the details of now, something to do with shifting an integer left and it suddenly turning into a long int and either a) not turning negative as I had expected when I OR'd in 0x80000000, and/or b) throwing an exception when I tried to mask it by ANDing with an integer value. Don't quite remember the exact details any more, but it was a WTF moment for me when I finally figured out that the type of the result of an operator could vary according to the particular integer values it was applied to.

    If you want to write C, just write in C.

    That's how I would have done it if I had written it (scripted languages not my first choice for a cpu simulator!), but I was just stuck with maintaining it and had to figure out WTF was going wrong.

  • (cs) in reply to Anonym
    Anonym:
    Josh:
    Wyrd:
    ...but the hype always said that Python makes programming easy, so maybe it's harder to *accidentally* produce bad code in it?

    You know, that's one thing I've never seen: a Python WTF. Anyone care to share? I'd pony up a $10 reward for Python WTF's but I'm too cheap.

    I'd like to see a real assembler WTF.

    Google "Story of Mel".

  • (cs) in reply to jspenguin
    jspenguin:
    Fedaykin:
    Wyrd:
    Except I'm not sure if that applies to Python. I haven't used it myself. I know it's possible to do wtf's in it if you actually try, but the hype always said that Python makes programming easy, so maybe it's harder to *accidentally* produce bad code in it?

    Python itself is a WTF. Invisible characters as a major component of your syntax? EPIC FAIL!

    Perhaps Guido was just trying to avoid holy wars about which brace style to use.

    Try this: Open your Python interpreter and type:

    from __future__ import braces
    

    Then you don't have to worry about whitespace anymore.

    <boggle> You can do that in Python? 'scuse me, I'm just off to try
    from __future__ import lottery_numbers
    
  • (cs) in reply to Mike
    Mike:
    Wyrd:
    The Real Problem with, well basically *all*, computer programming is that the set of ways that you can do it wrong is far greater of the set of ways to do it right.
    The problem with, well basically *all*, spoken language is that the set of ways that you can answer questions incorrectly is far greater of the set of ways to do it right.

    (but seriously, what you just wrote was one of the most ignorant things I've ever read on this website)

    It does kind of assume that programmers write code by pressing keys randomly and hoping the resultant program just works, doesn't it?

    Hang on a minute though - isn't that how programmers do write code? Isn't that why we're all here in the first place?

  • Anon (unregistered) in reply to Scarlet Manuka
    Scarlet Manuka:
    The main WTF is that instead of using Excel's built-in function to count the number of non-blank cells in a given range, the code loops through each cell, does a text replacement on the contents to remove manual line breaks, and checks to see if the result is empty.

    A subsidiary WTF is that if a non-empty cell is found, the code continues to loop through all the remaining cells in the row, rather than ending the loop at that point.

    From a professional, yes, but it's clearly stated it was an amateur, who really ought to be forgiven such things.

    The real WTF is that the consultants who came in didn't recommend replacing the partially automated solution with a professionally developed, fully automated solution.

  • (cs) in reply to Waffle

    Thank you, thank you! for submitting this. Although not a programmer even I can see the WTF-ness of this, and I can also see past employers' IT practices wherein one department, usually HR and accounting, had their own "IT gurus" who usually weren't much good but had special "suck up talents" and were very protective of their territory. "Security" was the usual justification for such a setup, which makes no sense. Better to have another pair of eyes watching. It's actually worse security to have only one guy running the system - what if he goes bad?

  • Mr.'; Drop Database -- (unregistered) in reply to Yann
    Yann:
    Yes, that is quite ugly. It relates to how dynamic the language is - which makes it fairly inobvious. Basically, any function you shove into a class becomes a method:
    I know. It doesn't require an explicit self parameter any more than Javascript requires an explicit 'this' parameter. Javascript does have some semantic surprises with its implicit 'this' but they're entirely avoidable. The main issue is that the Python developers simply refuse to fix it.
  • stiggy (unregistered) in reply to Havstein
    Havstein:
    chrismcb:
    CodeReview:
    can we all just agree that return (expression == true); does the same thing and stop fucking around?

    Sorry, can't agree to that. Why not just say:

    return expression;

    Of course maybe you expect expression to return FileNotFound, in which case you really want to return false?

    You're wrong. Needs more evalution: return ((expression == true) == true);

    But if you really want an exception, you could keep chainin' those evaluations and hope for an OutOfMemoryException.

    I prefer stack overflows

    bool IsTrue (bool expression) { return IsTrue(expression); }

  • Mr.'; Drop Database -- (unregistered) in reply to stiggy
    stiggy:
    bool IsTrue (bool expression) { return IsTrue(expression); }
    bool IsTrue(bool b) { return !IsFalse(b); } bool IsFalse(bool b) { return !IsTrue(b); }
  • Anon (unregistered) in reply to CodeReview

    Do you seriously care about points as utterly insignificant as this during your code reviews? I'm not even sure it's worth the time it would take to point this out.

    My code reviews aim to report two types of items: broken and 'may break'. Broken means there's a bug, may break means under load/large data sets/other environments/future conditions, there may be a bug. We don't always fix the 'may break' ones.

  • Waffle (unregistered) in reply to Anon
    Anon:
    From a professional, yes, but it's clearly stated it was an amateur, who really ought to be forgiven such things.

    The real WTF is that the consultants who came in didn't recommend replacing the partially automated solution with a professionally developed, fully automated solution.

    What makes you think they didn't ?

    Unfortunately, the power leverage of a consultant in the HR department of a huge banking firm is somewhat... limited.

  • quintopia (unregistered)

    I think the guy's problem is that he hasn't learned that if statements don't have to include an else statement.

    What he was good at was the more important part: giving people more work to do. More work means more jobs means more people getting paid. A true patriot if there ever was one.

    Even more importantly: He was able to convince these people to let him remain working for them even while increasing the amount of work they had to do. And getting money by applying a skill you don't have is a skill in and of itself.

  • Ryan (unregistered) in reply to Waffle

    Fortis?

  • Ryan (unregistered)

    I should add that I see this stuff all the time. That is systems based on Access and/or Excel.

    Access can be useful for these ends, but only when connected to SQL server. It's terribly unreliable and slow when the data's stored in Access. Otherwise it can provide solutions to problems in an extremely short timescale - which seems to be the cause of these sorta things.

    In both England and Netherlands.

    It's worse with Government-related things, though. Much worse.

  • Nile (unregistered) in reply to Voodoo Coder

    As far as I can tell, the function is testing for an empty cell. Any empty cell, not just the special case of an entirely blank row.

    This is a surprisingly difficult task in Excel, as there's no concept of NULL and an 'empty' cell may contain a zero-length string or a numeric zero - and it's difficult to predict what an inspection function like IsBlank() or IsNumber() will do because the casting functions for imported csv files are unpredictable.

    You may well be reduced to checking every single cell if attempts to use Range.End(xlToRight) and Range.CurrentRegion have proven ineffective.

    Even so, the function is badly thought out and badly coded; and examination of the function itself should not distract us from considering it's fundamental flaw - namely, that it should not be needed at all, as there are better ways of importing csv data, both to Excel and to MS-Access.

    And, indeed, better system architectures, although that might be beyond an amateur programmer: 'big picture' thinking and analysis doesn't come easy to people who started out on code alone.

  • (cs) in reply to blabla
    blabla:
    Tom:
    hamBone:
    I am far from a VB guru, but what in the name of binary is the teller=teller line about?
    It was running on a symmetrical multiprocessor. You need the same number of instructions on both branches of an "if" statement, to maintain symmetry.

    I don't think teller = teller + 1 produces the same amount of instructions as teller = teller

    Think one more time, O non-Z80 guru:

    teller = teller + 1 => INC A => 0x3C teller = teller => LD A,A => 0x7F

    An optimising Z80 compiler (is there any such thing?) might even convert the latter into a NOP (0x00).

    What do you mean, there's no reason to suppose that "teller" will be loaded into the accumulator? Obviously it's the most important variable in the whole dang function.

    And if you're going to complain about the difference in clock cycles ... well ... that wasn't part of the rubric. I dimly remember that INC A takes one, and I strongly suspect that LD A,A also takes one. If not, you're gonna have to rely on your trusty optimising assembler.

    Now, does anybody out there have the time to waste building a symmetric multiprocessor out of Z80 chips? I mean, the goddamn things probably cost less than a cent each these days...

    Oh, and for those looking for Python WTFs, try the entire os and sys packages for starters. Garnish with severe abuse of exceptions, decorated nicely with the dismal default output thereof, et voila!

    I truly love Python, but sometimes it gets on my tits. Idiots mixing space and tab characters do not, however. Python is capable of parsing itself, so there are a couple of neat little programs to sort this particular problem out which can be downloaded from the Web.

    I've got one, but I'm not going to share it until somebody builds me a Z80 SMP machine for $1 and a cup of Joe.

  • David (unregistered) in reply to Fedaykin
    Fedaykin:
    Wyrd:
    Except I'm not sure if that applies to Python. I haven't used it myself. I know it's possible to do wtf's in it if you actually try, but the hype always said that Python makes programming easy, so maybe it's harder to *accidentally* produce bad code in it?

    Python itself is a WTF. Invisible characters as a major component of your syntax? EPIC FAIL!

    Check out whitespace then:

    http://en.wikipedia.org/wiki/Whitespace_(programming_language)

  • David (unregistered) in reply to hothead
    hothead:
    I suspect the more likely scenario, is that little Rob came up with this code at home (that is unpaid, and without authorization), and his coworkers simply adopted it.

    More likely it was done at work - Access usually ships with Office Pro, and the license is a bit pricey for home users. On the other hand Access and VB are on most corp desktops since they come with Office pro.

    The sad thing is that Excel and Access with VB are almost always the only development "solution" available on the average locked-down corporate desktop. It's just a case of using a hammer because it's the only tool in the box.

  • Hyuga (unregistered) in reply to Josh

    Read comp.lang.python. It usually has several of them every day, usually unintentionally.

  • hoodaticus (unregistered) in reply to weirded verber
    weirded verber:
    yes... c-pound. I like C-Pound for the error handling

    wtf?

  • (cs) in reply to Procedural
    Procedural:
    One thing that annoys me with the way the story is told is this: obviously this is an old institution. Some guy (Rob) has the foresight to replace what must have taken a whole cadre of employees a large chunk of time to do manually or on outdated equipment and makes it so that it can be done with comparatively minimal staff. He's no programmer (he says that doing VB is a hobby), he's an HR guy with competencies beyond those of the typical HR person. Good for him. Great for the company too.

    The system works better than the older one but is still suboptimal and does not scale. So they hire a consultant to make it snappy, and that pompous ass shows up, laughs at what was done, dumps on the other guy, and fails to realize that the problem is relatively small: if Rob hadn't been there, it wouldn't be one consultant showing up to fix it; it would have been a whole team. So a non-programmer doesn't know how to return a boolean in the most effective way ? So freaking what. He probably saved his employer a lot more than the wages he ever took in (and was probably not paid that much more about the baseline HR salary to come up with that).

    Ten years from now, some schmo will show up thinking he is God's gift to computing sciences, and will see that whoever was that idiotic consultant, he made a few mistakes: he designed stuff that obviously wouldn't scale well on quantum processors (the idiot !), relies on MS SQL (which by now is an embeddable component barely good enough to hold the temperature history in my thermostat), and did ridiculous code that relied on procedural programming rather than intentional declarations (what a twit ! And they paid that guy money !).

    The funny part of the story is that consultant's deficient thought processes.

    Well said. A little too arrogant, maybe, but well-said nonetheless.

Leave a comment on “Enterprise Level Access”

Log In or post as a guest

Replying to comment #:

« Return to Article