• Old Fart (unregistered)

    var comment = _careerPlanRepository.GetAll() .Where(c => c.ChallengeHistoricalUnits <= units) .OrderByDescending(t => t.ChallengeHistoricalUnits) .FristOrDefault();

  • P (unregistered)

    "using EF/LINQ improperly" is really a massive pile of WTF on it's own.

    However, since they didn't just throw away the LINQ layer altogether and send out raw SQL queries through SqlQuery, they've failed as HPCs. If you need to do something, better do it thoroughly.

  • Network Noodling (unregistered)

    At a previous employer the board brought in a company of HPC to 'inject industry Best Practices and flexible thinking' into our small business. The original plan called for about 6 months of coaching us as we planned out the Big Rewrite.

    After three months of days-plus-overtime by the HPC we were (forcibly) transitioned to the WaterfAgile approach to task management, with a strict one-directional workflow pipeline: if a problem was found in a task then it had to passed all the way through the process before it could be reconsidered. As a completely new task. The number of tasks passing through the pipeline was one of the KPI.

    After that the HPC were handed total control of the Big Rewrite Project, where they rejected all recommendations by the SME and built a badly implemented data-centre-in-the-cloud, rejecting all managed services in favour of renting ever increasing amounts of server capacity and manually deploying 'best of breed' software stacks. I didn't play the political game and so got manoeuvred out of the company by the HPC, who actually held a celebratory party when my departure was finalised.

    They didn't like the idea of NOT using an ORM, even though the project was pure poison for an ORM solution. That's not the fault of the ORM, I hasten to add, but of the workload. ORM are generally not a good fit for bulk data load and ETL jobs involving rapid transformation of multiple millions of records. The performance of the ORM-based solution was around 5-20x worse than the original system, and required 4x the server resources. For reference, a POC that did it all by direct SQL access was 2x faster than the original and required about 25% of the server capacity.

    The HPC were fired a year or so later, by which time the Big Rewrite Project was almost three years behind schedule, still didn't include functionality considered critical for MVP, and was running at 15x the OPEX of the original (costly!) system it was supposed to replace.

    Happy days.

  • (nodebb)

    It takes a special kind of idiot to do so much worse than ORM.

  • Kev (unregistered)

    But.... they were still using the ORM in their solution, just not using the obvious Where clause

  • Anon (unregistered) in reply to Kev

    They did their best, replaced obvious use of ORM by stupid use of ORM.

  • Scott (unregistered)

    Reminds me of the HPCs where I work.

    When I got here, they were telling the company "you have to add more memory to the SQL Server machine", because we were getting reports of slowness/timeouts.

    There are about 50 users at any time. I told them they were full of shit, there's no way any SQL Server machine couldn't handle that load if we wrote decent queries.

    Found that the main search query was ADO.NET calling a procedure to construct SQL and returning all rows. So, this thing had the advantage of being susceptible to injection attacks as well as being inefficient.

    Suggested that we add EF to the project where this query was so we could take advantage of Skip and Take to only return the currently-displayed page's data.

    "Hurr durr, EF is too hard to maintain." In other words, we don't want to learn something new (to them, even though it's years-old technology that anyone in the MSFT domain should be familiar with by now.

    I went ahead and did it anyway. Surprise, surprise, we no longer have reports of slowness and timeouts.

    No, these fucking nitwits are still around.

  • Naomi (unregistered)

    Can I just bitch about the whole, "assign a variable and break instead of extracting a function"? I mean, maybe this isn't the best example because the control flow shouldn't be complicated in the first place, but still.

  • (nodebb)

    To be fair, earlier versions of EF were ABYSMAL at performance. They would break up a series of parent-child queries into separate queries for each child. And outer joins...forget about it. I could see some HPC saying don't use EF just for these reasons... The problem is EF "mostly" worked. You'd have to go through and hand-craft certain queries or not use EF in certain parts of your app if you wanted any sort of performance.

  • sukru (unregistered)

    You can always measure and then optimize.

    The good thing about .Net Entity Framework (or similar tools) is that they have good profiling support. If you actually run the program and trace the queries, it would be easy to figure out which ones are slow, and need manual attention. You can then just replace them with plain old SQL, and still get 80% of the benefits.

    But it you leave everything as is, yet EF will make your program slower.

  • Sole Purpose of Visit (unregistered) in reply to Mr. TA

    In general, a dubious proposition. I mean, you can do better, but for an LOB app, why not give it a go? If nothing else, the round trip between the schema in the DB and the object tree in your application is managed for you. Which is quite nice.

    But in this case, as I assume you are implying, what these goons appear to be doing is not so much to "throw the ORM away" (which I assume is part of their elevator pitch), so much as to try everything in sight for six months until they just go back and re-implement the original ORM solution, except that, because they are ignorant slobs, on the way, they've thrown away the central optimisation of running the "where" query on the DB server and substituted the moronic "grab everything" instead.

    Or, at least, that's how I read the OP. And I can't say I'm surprised. HPCs => O(n!) as far as I can see. Although they've obviously solved the no-halt problem by ... just walking away.

  • Sole Purpose of Visit (unregistered) in reply to Scott

    ^ Exactly what Scott said. (I think.)

  • Alex (unregistered)

    At my company they don't like Entity Framework, or any third-party library at all... unless it's DevXpress.

  • (nodebb)

    I've dealt with EF headaches on one of my projects (largely due to SQL views, e.g. to encapsulate complex and easy-to-screw-up business logic, or keep custom code in a separate database from the off-the-shelf software it's based on). But yeah, if you're replacing it then you should still do filtering within the SQL layer.

  • (nodebb)

    You cannot fire an HPC. You don't employ them.

    Of course, you can send them off with their usual contractual 6 months notice or so. Probably still cheaper in the end...

  • jendaPerl (unregistered)

    Whoever came up with this bloody _idioticRepository.GetAll() pattern ought to be hunted down and castrated with rusty scissors.

  • David Mårtensson (unregistered) in reply to Auction_God

    EF had some such errors to begin with but got pretty good at optimizing such queries the right way.

    Unfortunately EF Core lost some optimizations, which causes problems when moving existing EF queries to EF core as it suddenly makes the same mistakes as the HPC in the article in some cases.

    And even in the best cases, there are situations where EF just cannot compete with hand crafted SQL, but of cause, that requires not only SQL knowledge but intimate domain knowledge to understand exactly why and how to get the query planner to do the right thing and that also suns the risk that a new SQL version might require new tweaks to get the same result.

    But once you are working with multiple tables of billions of rows and need sub 100 ms responses, you do have to know your data (as in information) and how it behaves ;)

  • LPC (unregistered)

    To be fair I have, on a project a long time ago in a company far far away, made a call at the start not to use EF. It was a short project, neither me nor the (then) junior colleague I was working with had ever used EF in anger, the queries were simple, and it was a project to deal with data in an existing database. So I wrote a very simple single database ORM with little more than domain object property mapping and FK joins (which sat on top of direct SQL queries). Even then I knew about lazy execution of filters though.

    The worst part of stories like this is the way that the HPCs still get their money and get to walk away from the car crash.

Leave a comment on “Highly Paid Entities”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article