• (disco)

    Oh god yes. How many times have I seen a smart but technically clueless boss make stupid technical decisions because they don't know any better and get sweet-talked by a scam artist or clueless moron who only knows how to bang out SQL or XML or whatever.

    In most of my situations, the response to fire the consultant is "Why? It works, why mess with it?" without any idea why it really doesn't work.

  • (disco)

    I'm pleasantly surprised that the boss was willing to listen to the voice of reason. I know many who would have just doubled down and refused to change their mind for fear of appearing to have made a mistake.

  • (disco)
    Apparently, the consultant decided that every little thing should be its own class. No matter how small. A data object containing a Date was insufficient. No, there were separate objects to hold day, month and year, all of which were wrapped in a MyDate object. Ditto for time. Ditto for day of week. Ditto for everything else you could imagine. Then, to really test the capabilities of the IO subsystem, network and silicon, he would query every record in the entire database, construct objects for every component, sub-component, sub-sub-component, and so forth via Hibernate, and scan the list using the slowest possible mechanism in the Java language: instanceof, to see if an object was of a particular type before attempting to use it for purposes of comparison. To make matters worse, it repeated this entire process three times for each query; once to check if each business was of the proper instance for the region, once for the commerce-type and once more for the category.
    I want to throw up after reading that :mask: <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco) in reply to accalia
    accalia:
    I'm pleasantly surprised that the boss was willing to listen to the voice of reason. I know many who would have just doubled down and refused to change their mind for fear of appearing to have made a mistake.
    The boss was probably smart enough to realise that everybody that mattered (all his employees except the Architect) already knew he had made a mistake, which should act to neutralise or at least diminish that sort of fear. ("I'm afraid X will happen if I do Y. Oh, X has already happened, so OK, I'll do Y.")
  • (disco)

    Back in 2000 we were riding the last ripples in the waves of the Dot Com exploded bubble. Our company got major VC so we had to have some nice catchy technobabble to impress shareholders. You see, back then XML was this "thing", so our "portal" was "XML driven" no matter what that ever means.

    So, being a Microsoft shop, we set up a global ActiveX control, with some cache, and we processed XML with XSLT and generated HTML. Veterans from that time would like to point up that XSLT and XML support was, at best, flaky under Windows (MSXML2) so we actually had to change our XSLT code (and lot of XML namespaces, etc.) several time in the first year.

    Of course, XSLT processing was a costly operation, so we created a "document cache". It was a shared ActiveX object with a big array of strings (the processed blocks of text). It even had an admin interface, because if you changed your template, it would not know, so a developer had to go to a special page and press "clear cache". Hey, at least it was password protected!

    The real WTF is that it actually worked and that code lasted for about a decade.

  • (disco)
    kupfernigk:
    To what extent was Hibernate part of the problem?
    …I never mentioned Hibernate… <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco)

    Like I said: I never mentioned Hibernate.

    Of course. if you think that having heavyweight objects for things like day of the month is OK, and querying every single table in the database three times for each search is OK, then go ahead. But one thing is for sure: I'll never work on that code.

    <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco)
    kupfernigk:
    It wants to make everything into a college-project 3N structure.

    I'm fucking terrified of your database now if you consider 3NF "college-project stuff".

  • (disco)
    kupfernigk:
    To what extent was Hibernate part of the problem?

    The extent that they set it up to eagerly fetch everything, sounds like, which may have been a default back in the day. I don't know, but lazy loading is the default now.

  • (disco)
    an Architect who specialized in intelligent transactional agents
    Run away! Run away!

    http://www.anti-roboforex.com/uploads/0016aa64-0b81-4c22-aa58-90a90c9f2b9c.png

  • (disco)

    There was this guy. He wanted to build a house. But it was taking a long time because he was buying nails and other hardware one at a time. He would go to the hardware store, buy a nail, carry it to the lot, drop it in a box, then go back to the hardware store....

    That was bad enough, but to make it worse, he had just one box. Everything he bought was dumped into that box. So when he finished buying and needed something to build, he had to dig through the box for each thing he wanted.

    And that, boss, is why our product is so slow.

  • (disco) in reply to RaceProUK
    RaceProUK:
    But one thing is for sure: I'll never work on that code.

    But that builds character!

  • (disco) in reply to FrostCat
    FrostCat:
    But that builds character!
    No, it builds headaches.
  • (disco) in reply to leus

    Yo, I've been maintaining code of such nature only today. It's actually kind of a primitive MVC in a sort of way - procs deliver models (obviously not typed) which are delivered by controllers (in this case some VB code) to views (xsl). New projects are MVC proper of course but we have some customers not yet fat enough of wallet to have moved on. It's kind of not so bad in itself but the implementation is in fact a proper, serious, nuclear weapons grade WTF sighs I could do a few submissions but have not the heart yet...

  • (disco)

    An important principle of management, lost in these modern days of the MBA: You can't manage a team correctly if you don't have some basic knowledge about what they do.

    For example, most managers have a pretty good idea of what a salesperson does and how to judge their performance. If they aren't making calls, closing sales, and so forth, then you know there's a problem. Ditto for finance - if bills stop getting paid on time, or reports show up with incorrect numbers, or money isn't where it's supposed to be, that's an indication of a problem.

    And the tech team is no different. I'm not saying the Big Boss has to understand the intricacies of a Perl regex, but he does need to understand what the tech team can do for the company and how to determine if they're doing it. Otherwise, they will be fooled by somebody like this architect or a Paula Bean sooner or later. (It could have been a lot worse - companies like Accenture do that for a living.)

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    An important principle of management, lost in these modern days of the MBA: You can't manage a team correctly if you don't have some basic knowledge about what they do.

    QFT! This should be drilled into the head of everybody who believes that a manager is made by their MBA.

    EatenByAGrue:
    For example, most managers have a pretty good idea of what a salesperson does and how to judge their performance. If they aren't making calls, closing sales, and so forth, then you know there's a problem. Ditto for finance - if bills stop getting paid on time, or reports show up with incorrect numbers, or money isn't where it's supposed to be, that's an indication of a problem.
    Right, but most of those subjects fall under the heading of 'business' -- MBA types generally are familiar with those already.

    On the other hand:

    EatenByAGrue:
    And the tech team is no different. I'm not saying the Big Boss has to understand the intricacies of a Perl regex, but he does need to understand what the tech team can do for the company and how to determine if they're doing it. Otherwise, they will be fooled by somebody like this architect or a Paula Bean sooner or later. (It could have been a lot worse - companies like Accenture do that for a living.)
    is very true -- but the MBA types don't want to believe it, and the same holds true for *operations*. A MBA makes a lousy MOP or MYO, at least in their "out of box" state! My employer has a dedicated training track for prospective field management for that very reason -- if you tried to run a railroad with nothing but what a MBA gives you, you'd run the business into the ground, or worse, have the FRA and NTSB asking you some very hard questions about what you were doing with the capital budget...
  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    You can't manage a team correctly if you don't have some basic knowledge about what they do.

    Being an EE, I only work in tech companies, so my experience is different from being in a tech position within a non-tech company. Every manager was an engineer first before being promoted into management. (In some cases, they shouldn't have been made managers, but that's a different discussion.) The CEO may have come from the business side of the company, but management of tech departments up to at least the VP level usually has the technical background to understand technical discussions. Of course, business reasons (too expensive, schedule is more important than Doing It Right, etc.) may drive technical decisions, but at least they understand the implications of what they're deciding.

  • (disco) in reply to leus

    Heh, well, yeah, our code was horrendous, and we used (of course) Name-Based Filesystem Powered Backup Versioning System, a.k.a. 'bak1.bak2.bak3'.

    Also, our deployment system was to copy everything to a network share. A real story: one of the devs had the production directory mapped as a drive in his PC because why not, and then came this virus which was kind of famous back in 2000 that renamed files to .JPG extension, or corrupted them or something like that. Well, he got this virus, and of course, the server was immediately affected too. Fun times...

    Wish to say that I wasn't responsible for this, but ugh, I totally was.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    ("I'm afraid X will happen if I do Y. Oh, X has already happened, so OK, I'll do Y.")

    Just because everybody knows it has happened, doesn't mean the boss is ready to admit is has happened.

  • (disco) in reply to tarunik
    tarunik:
    A MBA makes a lousy MOP or MYO [...] FRA and NTSB

    TLA overload!

  • (disco) in reply to another_sam
    another_sam:
    tarunik:
    A MBA makes a lousy MOP or MYO [...] FRA and NTSB

    TLA overload!

    The NTSB is there to protect you!

  • (disco) in reply to dcon
    dcon:
    The NTSB is there to protect you!

    From TLAs?

  • (disco) in reply to another_sam
    another_sam:
    From TLAs?

    Of course! The FLA protects you from TLA Laceration Accidents.

  • (disco) in reply to another_sam

    Apologies for the TLA overload:

    MBA -- conventional meaning ;)

    Where I work: MOP -- Manager of Operating Practices -- supervises mainline train crews over a portion of the RR MYO -- Manager of Yard Operations -- supervises a railyard

    In the USA: FRA -- Federal Railroad Administration -- the US RR regulator NTSB -- National Transportation Safety Board -- the (rather famous and busy) US transportation investigatory body.

  • (disco) in reply to RaceProUK

    Sounds like the kind of stuff they taught us in university!

  • (disco) in reply to DocMonster

    To make situation worst, I once took over a (non-inhouse) web-based project from a left staff and see it uses a lot of things that no sane administrator would have allowed on server (requires separate copy of MS Office, and require domain admin account to run, just some obvious example) And when I suggest rewriting at least the most problematic part, my boss say he don't want me to and I should live with it.

    I submitted my resignation the next month. (For this issue and other "little things")

  • (disco) in reply to callcopse

    I'm inferring (i.e.: reading into that more than what you explicitly said) that the customers who pay less get the more expensive service.

  • (disco) in reply to Maciejasjmj

    Strict 3NF can't always optimally exploit performance characteristics of the RDBMS. The table examples give in the Wikipedia page on 3NF illustrate that nicely: In the 3NF-compliant form, you have to perform a JOIN to get the birthdate of the winner of a particular year, and JOINs are generally bad for database performance.

    Also see Denormalization.

  • (disco) in reply to another_sam
    another_sam:
    Just because everybody knows it has happened, doesn't mean the boss is ready to admit is has happened.
    Whence the caveat "or at least diminish". And I said this boss was smart enough to realise that everybody knows, which isn't the same thing as just everyone knowing. But yes, there are those who will refuse to admit it even then, although I wouldn't call them "smart enough"...
  • (disco) in reply to unwesen

    Meanwhile here in the real world update anomalies are still far more fucking annoying than joins are expensive. But yeah, there are cases, yadda yadda, just not that many that make much sense.

  • (disco) in reply to Watson

    Not totally, they just get the service they pay for at the time, and if it happens to be at the time when things are done by method A then that's what happens. If they can afford to update to modern method B they do but if they limp on for over 10 years on method A they don't, but you're correct in that ongoing dev and support costs do ramp up on the limping choice. Of course it is possible to avoid the extra costs by paying for the upgrade to method B but it's often a less chewable lump sum. What a business eh, bit rot feeds my family, what can you do etc.

  • (disco) in reply to callcopse

    In the real world, JOINs are so bloody expensive, that an entire generation of developers is flocking to NoSQL to avoid them (and ignoring the lessons learned by RDBMSes, but that's a different story).

  • (disco) in reply to unwesen
    unwesen:
    In the real world, badly designed and poorly indexed JOINs are so bloody expensive, that an entire generation of developers is flocking to NoSQL to avoid them designing their databases properly.
    ­ <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco) in reply to RaceProUK

    Yes, and designing databases properly avoids 3NF and JOINs. Glad we agree.

  • (disco) in reply to unwesen

    Actually, no. In a well-designed database, JOINs make heavy use of indexes, and are therefore not a performance bottleneck. If you design a database to use no JOINs at all, then you end up with a massive amount of data duplication, which then leads to massive headaches trying to keep it all consistent.

    Basically, a well-designed database should be in 3NF as much as possible, only dropping to 2NF to gain performance if no other means are viable.

    <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco) in reply to unwesen
    unwesen:
    In the real world, JOINs are so bloody expensivedevelopers have so little knowledge about modern databases, that an entire generation of developers is flocking to NoSQL to avoid them (and ignoring the lessons learned by RDBMSes, but that's a different story).
    FTFY
  • (disco) in reply to unwesen
    unwesen:
    Yes, and designing databases properly avoids 3NF and JOINs. Glad we agree.
    Maybe it's time to upgrade to a more recent database, say one from the 90s or later.
  • (disco) in reply to RaceProUK

    Until you try to populate a datawarehouse, then the indexes cause a performance bottleneck

  • (disco) in reply to Vault_Dweller

    Well, OLAP is another story. Then you generally do not want 3NF.

  • (disco)

    All this RDBMS mumbo jumbo is fine until you start doing coding in any language which is not SQL, mapping to real stuff and nesting thousands of JOINs only to get a freaking model.

    You all like your SQL and that's fine, but I hate the fuck of it, and even though I see when and RDBMS is the solution and when it's not. Luckily today we have several popular and production ready options like document, key/value and graphs stores, which allows many many many hacks in RDBMS to be burned in fire.

    In conclusion, TRWTF is storing all your data in a single system, be it an RDBMS or be it a NoSQL store.

  • (disco) in reply to Vault_Dweller
    Vault_Dweller:
    Until you try to populate a datawarehouse, then the indexes *cause* a performance bottleneck
    I'd rather the writes go a bit slow if I get faster reads later; data is read far more than it is written ;) <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco) in reply to Eldelshell

    If you need to "nest thousands of joins" then you're having a major WTF all in itself, regardless of what tools you use.

    I've been designing and developing applications in a variety of languages for almost 20 years now, and I think I can count the instances where I had to use more than say 10 joined tables at a time, probably on one hand, definitely no more than two.

  • (disco) in reply to Eldelshell
    Eldelshell:
    All this RDBMS mumbo jumbo is fine until you start doing coding in any language which is not SQL, mapping to real stuff and nesting thousands of JOINs only to get a freaking model.
    If your mapping requires thousands of nested JOINs, then your mapping sucks donkey balls. <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco)

    Is there a badge for people that don't recognize exaggeration/magnification? We've got two winners here.

  • (disco) in reply to Eldelshell
    Eldelshell:
    Is there a badge for people that don't recognize exaggeration/magnification?

    I'm sure @blakeyrat would also appreciate that.

  • (disco) in reply to Eldelshell
    Eldelshell:
    Is there a badge for people that don't recognize exaggeration/magnification?
    There's always flag for whoosh…

    Wait… what am I saying? Do I really want more whoosh badges than @accalia? :laughing:

    <!-- Emoji'd by MobileEmoji 0.2.0-->
  • (disco) in reply to Eldelshell

    So the point you tried to make doesn't really exist.

    I'm always open for a few more badges. :relaxed:

  • (disco) in reply to nerd4sale
    nerd4sale:
    So the point you tried to make doesn't really exist.

    Really? You haven't been around here for long?

  • (disco) in reply to nerd4sale

    See e.g. Why NoSQL can't write. It goes into a lot of depth on NoSQL problems, but it also illustrates quite well what the strength and weaknesses of RDBMSes are. This is from a guy working for MySQL, he really knows this stuff. The upshot is, you cannot rely on an RDBMS doing everything well with 3NF at scale.

    If you don't have scale, of course, do whatever the hell you like. But if you don't have scale, you have a college-level problem.

  • (disco) in reply to unwesen
    unwesen:
    If you don't have scale, of course, do whatever the hell you like. But if you don't have scale, you have a college-level problem.

    Just because a data set is small by Google/Facebook/... standards doesn't make it any less business-critical (!)

    My problem with RDBMS isn't RDBMS, though, it's asinine database designs that mangle foreign key handling to the point where you have to INNER JOIN ON INSTR(list_of_children, child_pk) > 0. Now that is database performance murder! (I strongly suspect that there is no index on this planet that will speed that query up, too -- if you know of one, though, please, please tell me!)

Leave a comment on “Consultant Designed Success”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article