From: Memmer, Richard
Sent: Wednesday, July 10, 2024 3:24 PM
Subject: we’ve never developed four deployments in parallel — but we just did
I finished this email before I got fired. Please pass the technical portions along to your next developer. If he or she has any questions, feel free to reach out and I’ll do what I can to guide them.
Thanks for having me here,
Rick
************
And yet the expectation was as if we were doing one. Please hear me out as I show you how that expectation could be a reasonable one (and solve all kinds of problems to boot). I’m in a great mood and after I send this, I’m gonna go right back to doing what I’m asked to do. But it’s in ECOLAB’s best interest to adopt at least the bare-minimum option below (which is simple and could be turned around in a few days):
On the surface, some minor structural changes and a few new files seems straightforward (and it should be). But we didn’t design for scalability—we designed to meet [her] skillset (which was fine to get things off the ground, but all development after APW2 should have been in my hands). With a more sophisticated approach, we would have created simplicity (so accommodating the needs of each deployment would have been a breeze). But we designed to meet [her] needs (thereby creating complexity through overlap and duplication). We’re even changing the underlying structure when it doesn’t need to be (simply because she doesn’t want to see any excess columns).
In talking to Diane about this on Monday—she gave me an idea that I should have thought of a long time ago (especially since we’re already doing it in other places). Awhile back, we solved our mapping table problem by switching it to a view (so now we maintain dbl_Spec_ZMFGLOC_Map_EPICMfgPlant_EBS_PlantID in one place—and no code changes on her part since we kept the same name). That is how we should be thinking about everything (to whatever degree that time permits). If moving to one database isn’t an option right now, we should do the next best thing (which is Diane’s idea on a view). Once again, this change would require no changes in [her] views. Just by having that conversation—an opportunity presented itself. But we don’t have those kinds of conversations here—because everyone’s in a rush to take care of the moment. But guaranteed, in just few days—we could have standardized all templates across deployments, went to views as a base for [her] views—and all these problems would disappear. We could make those base views table-driven as well (with a metadata table holding all columns across all databases). So if [she] didn’t want certain columns and wanted to add others, she’d just flag them in the table and re-run a procedure to re-create the view(s).
With the time zone difference, communication and fluidity of development are all the more imperative (particularly on a project of this nature). If someone wants to be part of the development process, they should be nimble enough to add a missing column instead of waiting to tell me about it the next day. Moreover, that should not be seen as a burden—but rather as an opportunity to grow (and little by little, start to understand the design considerations I’m trying to impress upon ECOLAB). I’ve got a list of issues on the files, but like I told Diane—I just fixed them so that I could keep moving. In hindsight, I should have stopped doing that a long time ago—not because I mind fixing some “minor” issues with tabs, column names, criteria and such, but because every “little” change interrupts the stability of the process and design. And with doing 4 deployments at once, it adds up.
I’m documenting the list of issues I ran into and changes we need to make, but I kept going. I provided the details in the file images below—and this is what I get in return: “Please load, validate and confirm that you have completed your reviews and task (flat files load) so I could move forward with mine. The structure of all tabs has to be loaded, and the data for those for which it is provided.” That file – IS the confirmation. I have gone to great lengths to advance and automate our processes (far more than anyone realizes). But ECOLAB (and especially [her])—wants to have its cake and eat it too (by not allowing me to fix the underlying problems and then being disappointed when I miss a few things—after I just put 4 deployments in play in as many days (complete with automated jobs and all). I’ve been working on processes to validate our counts, but I hadn’t had a chance to finish them yet. I signed off at 1:00 AM Monday morning and didn’t have a chance get to the counts, but I thought she had what she needed to get by on her views that night. The disappointment was palpable (right on cue). This “self-validation” idea has gotten totally out of hand with the level I’m required to do (particularly because I’ve taken the initiative to improve our processes while being met with resistance every step of the way).
We didn’t invest in the future last summer when we had the perfect opportunity to do so. We had a window of opportunity in the new year, but with [her] being out on medical leave and all that followed, we lost it. But we have another window right now (and with [her] not working full time for an undetermined time), it’s all the more critical that you consider our options.
- At minimum, we should standardize all templates and adopt Diane’s idea on the view. We would display only the columns needed for each deployment (maintaining our structure and adding new columns as needed). And I’d create the table-driven creation of the base views as described above. With all that’s in place now, we could knock this out by Friday (with me consolidating the templates and [her] reviewing them for approval). And going forward, any file that doesn’t meet our established standard (tab name, column name, whatever—gets sent back for correction). By doing so, we’ll get everybody into the habit of adhering to the standard.
- If all we did was #1, that alone would be huge. But I’m recommending we go further. It’s time to take those views out of her hands (which eliminates delays in development). She would document the logic and I’ll make all database changes going forward. For now, I’d maintain her existing approach on the views. But as time permits, I’d start moving away from those views in a database.
- I’d design it with the idea of moving one database, but even if you preferred to stick to one—moving away from those views and going to procedures is the smart move
The stand-up meeting is getting increasingly uncomfortable—as [she] is still stuck on this “summary” that’s no longer needed. Outside of a couple of general questions, I’m matching up perfectly with her Exclusions Excel tabs (which is the foundation of everything from there). So as long as it’s right, the rest is gravy. As I have repeatedly explained, it was impossible to provide a summary of discrepancies without a completed process to render them (particularly because of the nature of the document’s dependencies and out-of-order sequence of steps). Once I returned to this task and had some time to review it, I saw some opportunities for major improvements (which didn’t come to mind when I was in I rush during [her] absence). There was no point in providing a summary of discrepancies on a process I could significantly improve (thereby eliminating many of the discrepancies I originally had). I went from a bunch of discrepancies to having none (with the exception of a couple of general questions to clear up my understanding on some minor matters).
And still she wants summary. As I’ve already said, I will compile a list of discrepancies on the incoming files as I go along (but I’m creating a ticket for each one in the process). By [her] addressing my findings in an incremental manner, those fixes could eliminate future findings (which is especially relevant in an interconnected process of this nature). Moreover, not working together in an incremental and collaborative manner is how we got here in the first place. By requiring this “waterfall” summary before she acts on anything (is potentially of a big waste of my time and hers (and does nothing to further the relationship in how we work together). In this ticket Task 678711 Testing Purolite UAT – I provided the SQL, screenshots, and detailed explanation on a problem that should be a crystal clear to [her] at a glance. But once, instead of simply addressing the problem—she complained that it wasn’t in a file.
Come on! If I can automate her 28-page document without any help from her, I don’t think it’s too much to ask that she at least take a look at a small task and give it a shot. I’m getting pressed in the stand-up on the time it’s gonna take for this validation, but I can’t say without a conversation with you guys and [her] about how we’re going to approach this. If time is of the essence—we need to stop wasting it.
Thanks for your time,
Rick