{{announcement.body}}
{{announcement.title}}

Stop Changing My Toolbox!

DZone 's Guide to

Stop Changing My Toolbox!

A Zone Leader talks about the impact corporate changes can have on feature teams when they elect to make tooling changes ...at the absolute worst time.

· Microservices Zone ·
Free Resource

As a feature developer, my goal is to deliver solutions that meet the needs of the customer. Where possible, I will lean toward a reputable framework to make life easier and eliminate boilerplate code. My thought process is, let those elements do common things in a way far better than I ever could.

As a part of my job — especially as a nearly 100% remote resource — I lean on a series of tools to help me be productive and communicate with other team members.

You may also like: 29 Top Tools for Building Microservices on All Levels

Some of those items are noted below:

The biggest disruption that I have continued to encounter, is when forced to change out one of these technologies.  

Can you imagine the distraction from having multiple tools replaced at the exact same time?

A Real-Life Scenario

A few years ago, while mid-stream on a project and heavily focused on a set of deliverables with aggressive target dates, the following toolset changes were placed upon our team:

  • Chat and Screen Sharing services were converted from free service to paid licenses.
  • Online Meeting Service was replaced...actually, two times within six months.
  • The git-based repository was changed...from a locally hosted solution to a fully cloud-based solution.
  • A portion of the ALM stack was replaced with a different product.

When asked why these changes were happening now, we were told that the changes were driven by corporate leadership and were non-negotiable.  There was mention of significant cost savings and ease of integration with corporate staff.  What was not evaluated was the impact on productivity.

As one might expect, the impacted team's productivity took a hit while trying to get converted over to use/familiarize ourselves with the changed tooling.

But Wait...It All Doesn't Work The Same

On the heels of the promise the team implementing the changes had our best interest in mind, we quickly found that the change in tooling had an impact on our ability to perform daily tasks:

  • Historical information (tagged and pinned for quick reference) was no longer available when converting from the free service to paid licenses — because a new instance was created instead of upgrading the existing service.
  • Teams no longer had the ability to spin up quick public spaces to facilitate cross-team collaboration.  We did not realize this was not going to be an option, until the afternoon following the conversion.
  • With all of the changes with the online meeting services, no one really knew which system to use — so usage drastically diminished in favor of less-productive forms of collaboration
  • Issues with security caused the Git-repository to not work initially, plus some of the historical information was also lost. Git Blame is not effective without history — which is a problem when there are a question and several teams who have worked in a particular class.
  • The new elements within the ALM stack caused a lack of insight that did not exist before. The way the system functioned was foreign to the entire team — causing additional time to determine answers to what were quick queries before the change was made.

All of these misses by the implementation team led to a drastic reduction in team morale and faith in the internal corporate resources.  This is really no different than any other social interaction — having been so let down by the cause certainly had an impact on the perception of those behind the changes.  The worse part is when future tasks are being driven by the same group: one cannot help but have some level of doubt toward the success of the initiative.

Conclusion

While I am certainly an advocate for corporations standardizing on their technology tooling and keeping costs under control, I feel like those impacted should have some stake in the decision.  Perhaps not to alter the final choice, but to certainly make sure their needs are known, as well as their timing - and impact on deadlines.

In the case of my situation, these changes were completed at a very crucial time in the project.  As such, delays were the result of these changes and the target date was missed.  As a collective, we were able to compute the time lost —  easily quantified by documented results compiled from outside resources.  To our favor, the third party results determined the target date would have been easily met had the distractions from the tooling changes not occurred.

There is an American proverb that states:

 "Don't judge a man until you've walked a mile in his shoes."

I feel like the proverb can be modified to apply to this situation, proclaiming:

"Don't change my toolbox until you've worked on my feature team for a month."

Have a really great day!


Further Reading

Tools and Techniques for Building Microservices

Tools to Help Manage Microservices

Testing Microservices: Tools and Frameworks

Topics:
web design & development ,team productivity ,distractions ,tooling

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}