SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Downside of Tool Autonomy


The Downside of Tool Autonomy

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)

Group: Administrators
Points: 651183 Visits: 21472
Comments posted to this topic are about the item The Downside of Tool Autonomy

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Dave Poole
Dave Poole
SSC Guru
SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)

Group: General Forum Members
Points: 65811 Visits: 4071
Depending what the tools are tool autonomy risks the creation of silos by creating pockets of knowledge.

I've been on a life coaching course that talked about four characteristics you possess when social networking
  • Consuming:- you absorb information from your social network
  • Contribute:- You share/create content for your social network
  • Connector:- You introduce people across the network. You recognise that the skills of Person A are relevant to Person B and proactively introduce them.
  • Creator:- You create the social network in the first place and ensure that it thrives.
How those characteristics apply to you will vary and there is no right or wrong answer. My point is that if you wish to adopt tool autonomy you need to encourage connector and contributor behaviour for it to be anything more than indulging prima donnas.

LinkedIn Profile
www.simple-talk.com
IowaDave
IowaDave
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1474 Visits: 666
I think this is a very important issue that Steve is raising and it also is a tough balancing act. Not embracing new tools/packages can mean missing out on easier/better/cooler ways of doing things, but embracing everything can mean a maintenance - and security - nightmare.

Having an "eyes wide open", thoughtful approach is best. If a developer wants to use something new, they should be able to make a case for it beyond "it's cool" or "I wanna", AND they need to be committed - and have the time - to passing on knowledge about it to others.
Rod
Rod
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30944 Visits: 2849
Interesting perspective, Steve. I agree with a lot of what you say, but not everything. As a developer, I do enjoy looking at new technologies and techniques. And I do agree with you that, if unchecked, some developers could run after the new and shiny all day long. But by the same token I think it is possible to so restrict developers to a list of "approved technology", that at the end of the day, the only thing they'll ever do is whatever was done in the distant past. I see, too often, the "Hey, VBA was good back 25 years ago! Who cares about the Web or mobile? Just write VBA code!!"

Kindest Regards,Rod
Connect with me on LinkedIn.
Eric M Russell
Eric M Russell
SSC Guru
SSC Guru (117K reputation)SSC Guru (117K reputation)SSC Guru (117K reputation)SSC Guru (117K reputation)SSC Guru (117K reputation)SSC Guru (117K reputation)SSC Guru (117K reputation)SSC Guru (117K reputation)

Group: General Forum Members
Points: 117275 Visits: 15446
I assume we're mostly talking in the context of programming languages, IDEs, and APIs. It probably doesn't matter if a team member starts using VSCode or Toad to code their SQL, so long as it's a widely trusted tool. However, I hope there arn't any teams who would start using something like a backup, issue tracking, or version control system without management's approval or knowledge, especially if there is already an official corporate standard that they're supposed to be using.


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Steve Jones
Steve Jones
SSC Guru
SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)SSC Guru (651K reputation)

Group: Administrators
Points: 651183 Visits: 21472
If you think restricting technology means banning all new technology, I'm not sure you read this clearly. At Redgate, we limit technology, especially in projects that often see staff turnover every year. This is to ensure that we work within a limited set of platforms, languages, etc. that everyone knows to some extent.

We allow this list to grow and change, either by adding new items or by removing old ones. There needs to be slow change in the way we write code, especially as new processes and tools prove to be better. Anyone is free to experiment, and that is encouraged. In fact, we have an F# guild looking to grow the usage of that language.

However. We do not just allow those new technologies to be used in revenue projects. We used to, and that resulted in some items being difficult to maintain.

This also applies to techniques examined in code reviews and internal packages/libraries/frameworks for building. We want to limit what's there. Not prevent new ones, and certainly ensure we can retire old ones, but to ensure that the staff can, and wants, to work with what we use.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
jasona.work
jasona.work
SSC-Forever
SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)

Group: General Forum Members
Points: 47460 Visits: 17046
Rod at work - Thursday, January 31, 2019 8:25 AM
Interesting perspective, Steve. I agree with a lot of what you say, but not everything. As a developer, I do enjoy looking at new technologies and techniques. And I do agree with you that, if unchecked, some developers could run after the new and shiny all day long. But by the same token I think it is possible to so restrict developers to a list of "approved technology", that at the end of the day, the only thing they'll ever do is whatever was done in the distant past. I see, too often, the "Hey, VBA was good back 25 years ago! Who cares about the Web or mobile? Just write VBA code!!"

I've worked in an environment where the developers (led by one of the company owners) always seemed to be doing two things at once:
  • Chasing the current "shiny thing" for the application
  • Keeping the back end on an unsupported "database" product that last saw an update in the early 90s
What this meant was, when "web based" was the current "shiny thing," they started developing a web front end of the application, while still using the same back end datastore, and did this with developers that were basically learning how to do a web site on the fly. Then, hey, let's move to something else for the front end...
So you end up with something that's a bear-and-a-half to support, has technical debt built way up, and who knows how much of the code is bodged-together-not-sure-why-it-works-but-it-does-so-don't-touch-it.

If you put in place a process to control the introduction of new tech, perhaps even requiring a well-thought explanation as to *why* TechX will be better / improve things than the current TechY, you can keep your technical debt under control, improve the supportability of your software, and (one hopes) get the developers / managers / etc to actually *think* about why they want TechX. If the benefits are worth it, you start using it. If the only reason to use it is "it's new and cool and all the cool kids are using it" then you shelve the idea.

jay-h
jay-h
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17163 Visits: 2830
I feel there is too much obsession with discussions of what's the next big thing, or what's the current high paid environment, as the buzzwords of 2 years ago fall out of favor (at least in the computer press).

Too much emphasis on change, rather than maturity. Spoken languages last for centuries, albeit with gradual change. Literature (things that can be expressed with the language) only develops over time. Over that time the shared experience of many people builds a solid conceptual literature (or a framework of existing programming solutions).

Jumping to a new tool every year or two works against developing a deep background of experience.

Too much time spent reinventing and relearning the wheel.

...

-- FORTRAN manual for Xerox Computers --
Rod
Rod
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30944 Visits: 2849
jasona.work - Thursday, January 31, 2019 10:17 AM
Rod at work - Thursday, January 31, 2019 8:25 AM
Interesting perspective, Steve. I agree with a lot of what you say, but not everything. As a developer, I do enjoy looking at new technologies and techniques. And I do agree with you that, if unchecked, some developers could run after the new and shiny all day long. But by the same token I think it is possible to so restrict developers to a list of "approved technology", that at the end of the day, the only thing they'll ever do is whatever was done in the distant past. I see, too often, the "Hey, VBA was good back 25 years ago! Who cares about the Web or mobile? Just write VBA code!!"
  • Chasing the current "shiny thing" for the application
  • Keeping the back end on an unsupported "database" product that last saw an update in the early 90s
What this meant was, when "web based" was the current "shiny thing," they started developing a web front end of the application, while still using the same back end datastore, and did this with developers that were basically learning how to do a web site on the fly. Then, hey, let's move to something else for the front end...
So you end up with something that's a bear-and-a-half to support, has technical debt built way up, and who knows how much of the code is bodged-together-not-sure-why-it-works-but-it-does-so-don't-touch-it.

If you put in place a process to control the introduction of new tech, perhaps even requiring a well-thought explanation as to *why* TechX will be better / improve things than the current TechY, you can keep your technical debt under control, improve the supportability of your software, and (one hopes) get the developers / managers / etc to actually *think* about why they want TechX. If the benefits are worth it, you start using it. If the only reason to use it is "it's new and cool and all the cool kids are using it" then you shelve the idea.


Ouch, that environment you described didn't sound like it was fun to support!

Thank you for your excellent input.

Kindest Regards,Rod
Connect with me on LinkedIn.
jasona.work
jasona.work
SSC-Forever
SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)

Group: General Forum Members
Points: 47460 Visits: 17046
Rod at work - Friday, February 1, 2019 8:36 AM


Ouch, that environment you described didn't sound like it was fun to support!

Thank you for your excellent input.

Nope, it wasn't. It didn't help that the relationship between the developers and the support side of the business was / is somewhat adversarial, either.

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum









































































































































































SQLServerCentral


Search