one for me. We all strive to learn, but we're more likely to learn (and remember!) from our failures. Highlighted perfectly by Buck Woody (T) in a recent tweet* that was part of the invite.
*Can we still call them that? Or is it a post? Either way, it sounds infinitely better than 'in a recent X', which seems like i'm either redacting something, or being overly amorous.
Failures, we've all had a few of that i'm certain, whether its because of our own shortcomings, other people's, unreleastic project goals, sunspots, a surprise Godzilla attack or simply budget constraints, it happens. From this however, the disappointment is something that often makes us remember what went astray, and how we can avoid (or at least try to avoid) making the same mistake in future. Especially in the case of Godzilla.
Especially in the case of Godzilla...
"Running would be a good idea..." - Jean Reno 1998.
Indirect Stakeholder Management
I've had this occur in similar ways more than once so i'll focus primarily on this. All stemming from a project's inception, requirements set out and signed off, a design created and off you go. However even though the project is set out and officially approved, not everyone may be on board fully. This gets more important when there are multiple teams involved as some will be indifferent to the change, others massively in favour, particularly with anything security related.
What have I taken from this? Well, particularly in the case of SQL server and its reliance on the platform its sitting on...there will be other teams that may be impacted, or have an interest in by the project. Due to this, reach out to the other teams early, and take the time to explain what it is you are doing, and why. By doing this, you also leverage the knowledge of the other teams better, where one of those may pop up with "Hang on, do we want to do this / have to do this? Only i've seen this before, and it caused x,y,z..."
Its arguable that the Change/Project process should handle the approvals from the other teams, but sometimes they don't fully understand what it is they are approving, and they may have a long list of changes to approve each week and a short time to review them. Rightly or wrongly (its wrong imo), it happens and we need to try and mitigate for this.
In my case, the project was relating to SQL Encryption changes, and this ultimately had a knock on effect onthe DeDup ratio at the storage layer which then led to the project being put on hold by the teams who had previously approved it. Then cue one team pushing for it, another team blocking it and the poor little DBA stuck in the middle referring it to management as they're just the enabler here.
A lot of effort could have been avoided if we were all closer together during the project inception, and then during the testing phase as it may have been possible to spot issues earlier.
Along the same lines, and some organisations are more siloed than others, with teams not being particularly close. This makes the above more important (granted, and difficult) as i've had other architected and approved projects "pulled from under me" during the implementation phase. That example involved a project for SQL monitoring improvements, and making use of shared environments controlled by other teams. Liasing with members of the owning team of the environment had been from the outset, with them on board.
Although then it turned out, they weren't.
The use of 'a shared environment' became 'its our environment only' and the elements for SQL monitoring were lost, causing project failure. Political? Possibly. Healthy? Hell no.
From this i've learnt an additional things... to not only engage with the other team involved (which was happening thoughout), but make sure the hierarchy of that team is 100% on board as well. This helps serve to break down the walls between teams as much as possible and 'grease the wheels'. Whilst you can't influence the behaviour of the team directly, you can make sure that they see the benefits of the project and potentially save a whole lot of wasted effort and headaches in the meantime.
Tech Quick Fire Pain that springs to mind.
SQL on Linux. Insert performance was poor compared to Windows for the application in question - Learning: Don't assume that something will be better because the blurb says so.
Partitioning - Learning: It's not generally for performance, and trying to shoehorn it in for an existing application may not end well if performance improvements are what you have in mind. Being an early adopter of SQL partitioning waaaay back, I discovered this the hard way.
Resource Governor - Learning: make sure you RTFM first, and keep that classifier function super lightweight. See RG now with a busy system? First thing I do is see what the classifier function is up to.
Don't get me wrong, none of the above have put me off any of the platforms/functionality mentioned, I learnt LOADS technically from all of the actual work itself, and now I have better understanding of how to use it (or not use it).
Technical Skills.
From all of the above examples, as mentioned, i've learnt more technical skills, but i'm priortising that here I would have learnt the majority of those if the project(s) would have been a roaring success also. From the research, to implementation, new functionality in existing platforms, to new platforms/software completely, automation techniques. Loads.
Even though i've not included them specifically, the same applies. Doing something that doesn't work out as you would have liked sticks in the mind more than getting it all perfect.
I consider my brain like a bus, there's only so many seats and standing spaces available, and this is usually crammed full with the most recent knowledge and that I use often. Knowledge ages out as new knowledge passengers get onboard, with the old memories just leaving a calling card if I need to get back to them again (at which I start to remember the details). However, there is always the unruly section at the back, (usually on the top deck and surrounded by empty beer cans where the failures lie and the conductor fears to tread), these refuse to get off the brain bus, always shouting and screaming if they become relevant in any way. And you know what? I love them for it as its all about learning, both good and bad.
Thanks for reading as ever.
Rod the Gantt.