Please wait...
And I have a group of people who have never worked with any of these technologies.
They learned last week that we needed to have expertise on this, for something that needs to be rolled out ASAP.
We farmed out this product to a foreign developer and said
"it needs to be easy to install in the cloud and on prem".
That was it.
Then the buzzword-resume-enhancer they need is containers, not devops.
I think every technology shop should have a big sign on the wall that says "YOUR RESUME IS NOT OUR PROBLEM. BUILD WITH THE TOOLS WE CHOOSE."
Software architects need to choose the toolset and enforce the use of those tools. The tools they choose should be consistent from project to project, especially if the software is used outside the organization. Switching tools should be expensive and painful. For underlings, using a tool not part of the approved toolset should be *extremely* painful (as in, the door *does* hit you in the ass on the way out, and the door has spikes on it).
@ragnar, it certainly sounds like there is a disconnect here, but you and your team can not continue with a head-in-the-sand appraoch about Docker.
I find that they've built a new product, and are handing it over to operations who gave zero input (nor was asked for it).
This potentially sets us back, as no one on the team is really familiar with the technology.
I've probably got the most experience with Ansible and Docker, which isn't saying much. But then again, that's not my job.
Yeah...
* Find stakeholders
* Ask them what they need
* Work with software engineers to hash out a design
* Build it
* Iterate these steps repeatedly until you no longer make money
It doesn't seem smart to me to:
* Find developers
* Ask them what they need
* Throw together something you think will make money and enhance the developers' resumes
* Look for customers to sell the product you think will make money
* Repeat from 'Ask them what they need' until you shoot yourself in the face.
I worked at a place (late 90s, early 2000s) where the manager over the development team would every 3 months or 4 months request I purchase a new set of tools for a new programming language.
I eventually found out that every project was written in a different language. The manager would go to a client meeting, pick up a Dr. Dobbs magazine in the airport, pitch to the client the new application we were going to build, then write the new language that he learned about in the magazine in the contract. He would then go home, build a Proof Of Concept in the language, then tell his guys to write the whole application in this language.
The cost of the new tools, training, etc was never included in the contract, so we lost money on all of that groups projects.
I was on the systems side of things at the time (Network Administrator & IT Manager) and my boss the CFO warned me that systems didn't get along with developers and he wanted my team to get a long with the developers. When I found out that the Dev manager was doing this, I figured out why my predecessor didn't get along with that team.
Hell that team was getting so burned out by switching programming languages with each project it was amazing that any of them stuck around.
Sadly, not unusual at all, if the process was rushed.
It *ought* to be routine by the point you deploy the product. It *ought* to be smooth and silky. But, typically, management tries to push things to go faster, so the product pays the price.
No, I don't think so. I think he just thought everyone should be able to do that. I don't know his background really. I know his degree was in music, and he was a conductor outside of his day job. I didn't think he was a very good manager.
Thu Jun 07 2018 14:31:36 EDT from fleeb @ Uncensored
Makes you wonder if the person was intentionally trying to kill the team.
the development team would every 3 months or 4 months request I
purchase a new set of tools for a new programming language.
I've seen the results of that. Big gigantic mishmoshes of things built with different toolsets.
Any decent CTO would fire an entire layer of technical managers and hire someone who knows how to standardize.