June 12, 2020 at 12:00 am
Comments posted to this topic are about the item Are You a Gatekeeper?
June 12, 2020 at 12:11 pm
The eternal balance between law and chaos.
Standards are by their nature "gates". For example, would you really want five different voltage standards for household outlets? How about which side of the road to drive on? Or what about yet another system of weights and measures? (Imperial, Metric, and Goomba?)
In the tech world a company uses certain tools and languages because A) tools are expensive and B) languages are complex and take years to master (not just 101-level, but actually master). Somebody wants to use Rust, someone else Python, somebody else Java or VB.Net or (shudder) LISP...
So then anything the snowflake wrote in Scala and then quits means you either throw away all their work or find somebody else proficient with Scala.
I'm not saying be hidebound for the sake of lack of change, I'm saying standards are there for a reason.
June 12, 2020 at 1:31 pm
This all depends on WHERE you place the gate! If the gate is at the start of the process, then you will have problems. If the gate is at the solution, this will allow for various approaches as long as they will produce the same result accurately and consistently. This is not to say that the tools should necessarily be allowed to vary, but the USE of the tools might somewhat.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
June 12, 2020 at 2:35 pm
Agreed with both of the above, everyone creates their own gates because it helps their sanity. Being able to work with people means controlling the chaos from both sides and reaching a common ground. If you want to expand those gates, both sides have to be willing/able or things just get harder with no gain.
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
June 12, 2020 at 7:56 pm
Perhaps it is a shame to have to say it this way, but when I was younger, I had many problems with gatekeeper behavior, both my own and that of others. As I have gained experience, my irritation and dissatisfaction with gatekeeping have reduced to almost zero. First, I know that such pain is inevitable, and I no longer lose any sleep about it. Second, I have gained tools and techniques that enable me to make progress no matter what the gatekeeping behavior is. I guess that I can provide some modest advice about gatekeeping from my experienced position...do your best to make sure that you have the right people in gatekeeper roles, and give them the authority to go along with their responsibility. A final warning...if you get this part wrong, it is likely that the only symptom you will notice is that your best technical performers keep quitting.
June 14, 2020 at 3:07 pm
Just like the best managers, "GateKeepers" must not be just enforcers... they must also be "servant-providers". That doesn't mean they should just rollover and give in just because someone wants or "needs something real bad". In the world of DBAs, that means making sure there a viable development and test environments to enable others to do their jobs correctly and quickly without having to allow people to "develop in production". Ultimately, the DBAs have a huge responsibility in making sure that the SDLC works correctly and that it all follows a written spec for the SDLC because the DBAs have the responsibility for protecting the data and the machines it lives on. They're also the ones that will take the hit if there's a security violation or there are problems with audits (and, in the business we're in, audits are incredibly important).
DBAs can't just sit on a cloud and say "No". If you don't want Developers to have access (certainly, no access to deploy unchecked code to production), then the DBAs MUST provide viable work environments for Developers and Testers and ensure that the written SDLC is being followed to a "T".
Yes, there will be "urgencies" where there's a problem in prod that must be fixed NOW, but it doesn't mean that you have to violate anything in the SDLC spec. It just means that you have to greatly accelerate the SDLC for such problems. On the couple of occasions we've needed to do so, we've been able to follow our rather strict SDLC and get the job done in as little as 15 minutes.
The real key here is that our SDLC helps us avoid such "urgencies" by "doing things right the first time". It takes anywhere from no extra time to just a little extra time and saves huge amounts of time on rework, which typically takes 8 times longer than simply doing it right the first time. It also inherently creates an fully provable and audit-able process that will make both the auditors and your customers very, very happy.
Always remember that "if you want it real bad, that's the way you'll normally get it". 😀
Again, the "Gatekeepers" must not only be "enforcers". They must be enablers and providers, as well, but it has to be done right and in a highly audit-able fashion.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 15, 2020 at 8:09 am
I feel it is important to understand why the gates exist and just as importantly to determine if the gate can be replaced by a better mechanism. Test driven development would be an example of a gate keeper process that reduces the amount of gate keeping a human tester has to perform.
There is a WHY to gate keeping. Tools like the "5 whys" exist to help us drill down until we are addressing the root cause WHY. We don't want a gatekeeper for the symptom, we want it of the cause.
The other thing to address with gate keepers is fear. I've certainly been a gatekeeper operating in fear. If what you are proposing to do goes wrong.
I've not experienced #1 but I sure as hell have experienced the rest of them. Especially #4, over and over again #4. Eternally #4!
June 15, 2020 at 12:19 pm
... nothing is more permanent than a "temporary" solution?
David, I just have to add this to my collection on my computer that I call 'Bits of Wisdom'. I love this!
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
June 15, 2020 at 3:07 pm
I just read the article and I think I am a mix of gatekeeper and flexible. Some things I see as hard-fast rules that should not be debated with new hires or even peers. Like "are you taking backups and validating that they are good by performing a restore?". Other things I am more flexible on like the use of [] around object names.
With tools, coding languages, OS's, and even databases, it is all about picking the right tool for the job. If you have a team who has worked at the company for 20 years and their experience has been solely in VB6, you are going to have a hard time getting new hires in who know how to support your system.
The other thing that makes gatekeeping tricky is making sure your standards actually make sense. When I started, we had a standard that said to NEVER use CHAR or NCHAR, always use VARCHAR/NVARCHAR because it uses less resources. I challenged that to the lead DBA at the time and got told I was too new to be having those debates and to just follow the standards. After he left, I brought it up with the other DBA's and now we follow the "use the right datatype for the data" principle and the only datatypes we don't allow are the deprecated ones.
Gatekeeping should be done as a team (with the subject matter experts defending the decisions on the standards) and not just with a single dictator. The problem with the dictator approach is that it causes people to interpret the standards differently or to find loopholes in the standards.
At my workplace we have some things that are STANDARDS and we have some things that are suggestions. The standards are things that we will not compromise on (non-descriptive object aliases like "a" or "lb"), and the suggestions are in place for when you are not sure if you NEED to do a thing (like "do all tables in my query need to have an alias?") to have the code pass code verification.
Nothing worse for a developer than asking for code to be reviewed and released to live after it is fully tested only to have the reviewer tell them "this doesn't meet our standards" and they need to do rewrites on formatting and retesting to make sure nothing broke and potentially bump the release out by a day or 2. But nothing worse for the on-call person than getting a call after hours about how the new tool has a bug in the latest release that needs to be urgently fixed.
TL;DR - I like having Standards that are rules that you MUST follow in order to get your code approved for release, and suggestions to help reduce the number of questions that get asked to a DBA/Developer that really don't matter.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply