221

After listening to two of our senior devs play ping pong with a new member of our team for TWO DAYS!
DevA: "Try this.."
Junior: "Didn't work"
DevB: "Try that .."
Junior: "Still not working"

I ask..
Me:"What is the problem?"
Few ums...uhs..awkward seconds of silence

Junior: "App is really slow. Takes several seconds to launch and searching either crashes or takes a really long time."
DevA: "We've isolated the issue with Entity Framework. That application was written back when we used VS2010. Since that application isn't used very often, no one has had to update it since."
DevB: "Weird part is the app takes up over 3 gigs of ram. Its obviously a caching issue. We might have to open up a ticket with Microsoft."
Me: "Or remove EF and use ADO."
DevB: "That would be way too much work. The app is supposed to be fully deprecated and replaced this year."
Me: "Three of you for the past two days seems like a lot of work. If EF is the problem, you remove EF."
DevA: "The solution is way too complicated for that. There are 5 projects and 3 of those have circular dependencies. Its a mess."
DevB: "No fracking kidding...if it were written correctly the first time. There aren't even any fracking tests."
Me:"Pretty sure there are only two tables involved, maybe 3 stored procedures. A simple CRUD app like this should be fairly straight forward."
DevB: "Can't re-write the application, company won't allow it. A redesign of this magnitute could take months. If we can't fix the LINQ query, we'll going to have the DBAs change the structures to make the application faster. I don't see any other way."

Holy frack...he didn't just say that.

Over my lunch hour, I strip down the WPF application to the basics (too much to write about, but the included projects only had one or two files), and created an integration test for refactoring the data access to use ADO. After all the tests and EF removed, the app starts up instantly and searches are also instant. Didn't click through all the UI, but the basics worked.

Sat with Junior, pointed out my changes (the 'why' behind the 'what') ...and he how he could write unit tests around the ViewModel behavior in the UI (and making any changes to the data access as needed).

Today's standup:
Junior: "Employee app is fixed. Had some help removing Entity Framework and how it starts up fast and and searches are instant. Going to write unit tests today to verify the UI behaivor. I'll be able to deploy the application tomorrow."
DevA: "What?! No way! You did all that yesterday?"
Me: "I removed the Entity Framework over my lunch hour. Like I said, its basic CRUD and mostly in stored procedures. All the data points are covered by integration tests, but didn't have time for the unit tests. It's likely I broke some UI behavior, but the unit tests should catch those."
DevB: "I was going to do that today. I knew taking out Entity Framework wouldn't be a big deal."

Holy fracking frack. You fracking lying SOB. Deeeep breath...ahhh...thanks devRant. Flame thrower event diverted.

Comments
  • 27
    Wow! Good job mate!

    Also, "I would have done that. You know...if you didn't" yeah right!!

    Nice work nonetheless
  • 7
    They just envy you :-D
  • 8
    Should have created a microservices layer using EF, and make the app use them instead. Implement caching using Redis on those microservices, implement some fault contracts, secure the communication with a cheap certificate from Comodo, and you're done.

    But no. You had to make it complicated and move everything to ADO. You are the reason why dev world sucks.
  • 12
    Did you point this out to DevB in a feedback session? Are you having some sort of retrospective within the team? Did you escalate this as "Not cool! Why didn't you do it yesterday then?" Or did you remain silent?

    Such behavior is toxic, and if not addressed properly it constitutes a really a bad company culture. (And it sets a bad example for the junior who might think such lying behavior might be OK in the future.)

    I had the displeasure of working with a few of those people, don't let them get away with it. They aren't even a work subtractors. They are a frigging dividers.

    Teach them that such behavior shall not be tolerated, and if they persist, get them out of your team.
  • 2
    I would have replied with "yesterday in front of the manager you said it was impossible or would take months did you not?"
  • 1
    Guys, nice replies. I haven't been in such situation but I'll keep them in memory for future use!
  • 2
    You're a hero. I've had experiences with EF, and in situations like that, it's a horrible mess.

    Good job, don't care about lying colleagues. You deserve all the credit, and they should know it.
  • 4
    Moral of the story: remove EF

    Oh wait!...
  • 4
    @k0pernikus Its "sometimes" toxic. We actually have a highly cooperative integrated developer environment (a lot of good, smart individuals here). DevB is highly intelligent and a good contributor to the team. That said, DevB is a master at 'playing the victim' and can brilliantly redirect blame. It's an amazing feat to witness how he can easily manipulate management.

    Any retro with constructive criticism would have yielded a smile, a "thanks for the feedback, I'll work on that..", then within a day or two he'll stay late to "catch up" with the dept. manager..
    <small talk..then>
    DevB: "Had a retro the other day and Bob yelled at me for no reason. All I was trying to do was help Junior. I believe helping people is important, but Bob doesn't. I hear the other devs think Bob is an asshole too...Bob must think he's better than everyone else...right?"
  • 0
    @PaperTrail fuck those kinda guys, you have my condolances.
  • 0
    Oldest trick in a senior developers book. If something works, don't fix it. If something that works has to be tampered with, make sure someone else takes responsibility...
  • 0
    Next time you should try copy his tactics and be like "there's no way that's gonna work!" and "oh I could have done that myself!". I'm curious how he'd react.
  • 0
    @cyberlord64 As a Senior Developer myself, I can say this is not the case. I think you've just worked with the wrong people.
Add Comment