Ed Wagner (12/17/2014)
Grant Fritchey (12/17/2014)
WayneS (12/17/2014)
Jeff Moden (12/17/2014)
Koen Verbeeck (12/17/2014)
Brandie Tarvin (12/17/2014)
Brandie Tarvin (12/16/2014)
WHOO! #HappySnoopyDanceI just spent 2 & 1/2 days reworking a package and its supporting tables / stored procedures. Previous time of execution between 8 - 12 hours.
Current execution time ... < 5 minutes.
"Celebration Time, come on!"
Sigh. So I presented coworker with my changes and asked for a peer review. Partially to make sure I didn't miss anything, partially to give coworker a learning opportunity since coworker was the one who designed the package. There were 7 files / queries involved and lots of tables. The response I got when I told coworker was: "You redesigned all the queries? But only the one was giving us problems!"
Me, I'm looking at the package and seeing opportunities for cleaning up extra variables, reducing the number of containers in half by moving File System Tasks from one container to another and deleting the excess, stripping out code and variables that were built in the initial development and not used. Also, I'm seeing 7 procs where excrutiating RBAR WHILE loops are slowing down processing. Granted, 6 of those procs were not having issues because they are usually working on files that are pretty small. But that doesn't mean they won't cause a problem in the future. After all, the one problem we did have wasn't a problem when this process was first put into place.
And being fair, this package was the first major ETL process designed by my coworker. Coworker had a huge learning curve not only for SSIS but the 7+ files that were being sent from a different system. Using the code I got from the forums here, he redesigned one file into a separate package that worked effectively. The other package (with the other files) were left alone.
But still... To my mind, since I'm already fixing one part of the package, why shouldn't I proactively fix the rest of it to make sure the other 6 procs and ETL paths do NOT become a problem down the road?
Or am I just being too efficient?
I do the same.
Small bug in a T-SQL script?
Whoops, I reformatted all of the code and did some performance tuning 😀
I'm the same way. Just understand that it IS the co-worker's work and since everything was rewritten, that co-worker is feeling seriously wounded.
And that PC stuff is a skill that I haven't yet mastered. "Yeah, your stuff sucked, so I used the opportunity and my expertise to give it a tune-up."
Heck, I'm more diplomatic than this, and that's saying something.
But I agree Brandie, you didn't do anything wrong.
+1 to not doing anything wrong, but I'm not very diplomatic either. The technical reasons for fixing this are clear. On the human side of the equation, if you don't take the opportunity to fix and use it as a teaching moment, how can you expect the junior person to learn?
That might be the best answer (i.e. make it a teaching moment). I've had this exact scenario go seriously sideways (on the human side). Nothing like getting dragged into your manager's office to have it out as to why you "sabotaged" johnny's code.
When you find myself rewriting the whole thing, it might be worth stopping what you're doing, going to find these folks and pull them into the conversation DURING the rewrite. Bonus points if you can pull them aside and do it somewhat discreetly (not in front of an audience). Triple bonus points if you can guide them to make the fixes themselves (again - a huge "face-saving" tactic). If it doesn't go well - you can always escalate the issue and get air cover before you replace their work.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?