January 30, 2019 at 8:17 pm
Comments posted to this topic are about the item The Downside of Tool Autonomy
January 31, 2019 at 1:38 am
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
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.
January 31, 2019 at 8:07 am
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.
January 31, 2019 at 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!!"
Kindest Regards, Rod Connect with me on LinkedIn.
January 31, 2019 at 8:39 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 31, 2019 at 8:41 am
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.
January 31, 2019 at 10:17 am
Rod at work - Thursday, January 31, 2019 8:25 AMInteresting 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:
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.
January 31, 2019 at 11:21 am
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 --
February 1, 2019 at 8:36 am
jasona.work - Thursday, January 31, 2019 10:17 AMRod at work - Thursday, January 31, 2019 8:25 AMInteresting 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.
February 1, 2019 at 9:06 am
Rod at work - Friday, February 1, 2019 8:36 AMOuch, 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.
January 22, 2020 at 6:45 am
I have first-hand experience of a company which flirted with 'autonomy'. For a while, the developers could use pretty much anything they liked. They had fun and they were creative. They discovered first-hand that the complexity of what they had to support (the company does devops) was high, and knowledge handover was not always as complete as it might have been. Support was not fun. Some of them complained about a lack of guidance from the technical experts who many of them had conveniently ignored. Each autonomous team reinvented the wheels of backup and recovery (or possibly not if they didn't perceive a need for them). It took the arrival of new management with authority to improve things to deal with the obvious inefficiencies of multiple teams building multiple different solutions to very similar self-inflicted problems.
Now the company has a list of approved technologies. To get something new and shiny on to that list, a team has to justify it, perform a proof of concept and make it work and provide full support tooling for it through all stages of build and operations. Some of the developers complain that it's too hard and it hinders adoption of the new. I am hopeful that it is in reality a happy medium. Ideally developers should be applying their creativity to the application, while being free to rely on standardised tooling and infrastructure that works.
January 22, 2020 at 1:23 pm
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.
.....
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.
I think there is justification for a fairly strict limitation on the introduction of new technology. Not that I'm against progress, but the practicality is that safety of companies and their data has to take priority. I think you have to ask yourself how willing you are to assume the inherent risk of allowing a single person or a minority to implement things that might need to be maintained or improved by others if the original personnel are not available.
I'm not familiar with newer practices, but it has been my experience in the past that new technology was not implemented until there were sufficient in-house people qualified, usually by in-house group training, to assure the ability to support.
We definitely need to encourage the LEARNING of new technology, while at the same time tightly controlling the IMPLEMENTATION of it.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 22, 2020 at 1:50 pm
Our industry is beset by chasing the shiny. It happens on all sides of the house, development, operations, support...and it's deadly. Yes, if a new tool comes along that obviously blows the old tool out of the water absolutely it should be investigated, and time taken to really dig in and see what the warts are.
I've done Fortune 50 team development and lone wolf development. While the needs of the two are vastly different (lone wolves must be DevOps by definition, Fortune 50s not so much) neither one has time to chase the shiny-of-the-week. So much of our industry is exposed to what amounts to snake-oil salesmen that talk a great game but deliver so much less. Worse, they do it to managers who are all too often divorced from the trenches.
I'm in the enviable position as a lone wolf to be required to choose which tools I pick up. After forty+ years in the game I've become absolutely ruthless about the new shiny. Because I'm doing the work of developers, operators, DB admins, etc. my primary focus becomes is this new shiny going to shoulder some of my workload?
ModelRight does that. Redgate's SQL Toolbelt does that. Visual Studio and Crystal Reports and SSMS do that. And do it while letting me keep my (pitiable) budget from falling over.
You got a new shiny? Cool! Let me scrounge 15 minutes from my frantic workday and look it over. Will it do anything that saves me enough time to justify the hurt it puts on my non-existent budget? Ok, I'll go beg my boss for however much pain he's willing to endure from his boss.
It won't? Don't let the door hit you on the way out, you Sales Weasel!
January 22, 2020 at 5:22 pm
It can be dangerous for developers to download random tools from internet, especially tools that connect to the database. It needs to be from a trusted source like Microsoft or RedGate.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply