Confirmation bias is when "people tend to seek out information that confirms their existing opinions and overlook or ignore information that refutes their beliefs". As a result this hinders decision making and useful information is ignored that could benefit a business. Humans are notoriously creatures of habit, take someone out to a restaurant and they will tend to order what they know from the restaurant menu, rather than choose something they haven't had before and risk the unknown. This is despite the menu having a variety of different options, but these new options are seen as a risk, as they may not be as good as what we normally have or are used to having.
This same situation is prominent everyday in the IT industry when selecting vendors or tooling, we need to change this as it actually makes us bad engineers. More importantly having confirmation bias for one particular vendor or tool can have an adverse impact on a business, as instead of picking the correct tools for the job, staff will simply look up if their current vendor of choice and say its either possible or not based on one vendor or tool. When it comes to vendors or specific tools, it really concerns me that companies hire staff and put a particular tool name in their job title. It equally concerns me that people in IT still try and market themselves as an expert in only one technology, as all technology has a shelf life normally shorter than a career. Luckily we have seen this trend in the job market change from "x vendor admin" to more vendor and tools agnostic terms such as "engineer" which suggests companies are starting to see the error of their ways.
Anyone that calls themselves "x vendor expert" or "x vendor guy or girl", one would argue has already shown they put vendors and tooling at the forefront of importance, rather than the end goals of the business they are working for, or process they need to implement, which is a worrying trend. Those individuals in practice tend to be less open minded about the technology stack and probably more likely to exhibit traits of confirmation bias in favour of "x vendor or tool", when asked to make a technology decision. They will promote a particular technology to the extreme, while rubbishing competitors tooling without having taken the time to understand it or even use it. They have a tendency to ignore alternate or potentially better solutions due to the confirmation bias. Any new vendor or tool that may compete, they seek out negative information or blogs that justify their decision to promote a particular vendor. They will also seek out like minded individuals who also share their confirmation bias to justify it rather than road testing all the options.
This is very unhealthy behaviour, falling in love with vendors or tooling is very dangerous. I jokingly call this symptom "falling in love with the stripper syndrome" as I feel this best sums it up, for those looking in from the outside. The vendor becomes like a stripper to the client, the vendor will tell the client they love them, they are great all the time and very very important to the point the client believes it. By now the client is doing all the certifications the vendor provides, buying their software licenses and more than likely buying the books they have published. The rule here, is never fall in love with the vendor, their job is to make as much money as they can, they don't love the client, it's their job to take make money from the client! This may sound cynical but this is sales routine after all, and business, it's not a criticism of vendors.
What the DevOps initiative should have taught us by now is processes and ways of working are actually more important than the vendors or tooling, which should in theory be interchangeable around the process. My personal opinion is the best job title for people implementing continuous integration or continuous delivery is "process engineers" as this is essentially what they are doing, people need to be open to substitute out any vendor or tool if a better one comes along. Some will obviously be harder to swap out but as long as benefits the business then it should be possible.
Vendors and tooling should always come secondary to good processes that facilitate business needs. If using a particular vendor over another gives an actual business advantage, I am all for it, as long as desired processes are not compromised.
At all costs we need to avoid the tail (vendor) wagging the dog (company). If that happens the processes will suffer due to the short comings of tooling, which may not be the best available, and lead to vendor lock in. All software is flawed and vendors best practise guides tend to be a little divorced from the reality of everyday project needs and delivery, so the approaches that they provide under "best practise" very rarely tend to be the way customers are using the tooling in production. This is why it is important that vendors that are chosen listen to clients needs rather than setting a road map of what they think the client wants. There is a very important lesson in this, the biggest company in the market will very frequently not be the best partner. Take the football analogy of Ronaldinho, who was for a period the greatest football player in the world. Ronaldinho over a 2 year period won the European Cup with Barcelona, World Footballer Of The Year and then the World Cup with Brazil. Afterwards, Ronaldinho was never the same player, the issue with Ronaldinho was that he was no longer motivated, as he had won everything and therefore lost his hunger to go that extra mile. In vendor partnerships it is important for companies to partner with vendors that are hungry for success and will go that extra mile to support their business needs and sometimes that means going for those that are up and coming and still have something to prove.
Before making tools choices we should always write down a mission statement of what needs to be achieved, map out the current process flow, map out with your peers the new desired optimum process flow, making it as lean way as possible, then finally choose and map the best tools for the job to implement the desired process. I am still astounded that this never seems to be the ordering in IT when selecting tooling to implement process or automation. Typically I have seen individuals first select their favourite tool, or vendor they are familiar with, then try and use the "best practise" method recommended by the vendor in their certification course to implement it. This scenario makes me want to cry, as it forces vendors or tools to dictate process to companies, so companies build their processes around tools which is simply wrong. It may be a controversial statement but I actually believe in 2016 vendor certifications are worthless, I have benefited more from going to technology conferences. I do believe vendor certifications kick the inspiration and creative thinking out of people, the same way I would argue exams at university weren't as valuable as doing practical course work.
Rather than vendors telling us what we should be doing, we need to be pushing and moulding software vendors road-maps into what we need to achieve to meet our companies needs. This is why open source has come to the forefront and why I believe any company that doesn't open source their code will eventually have to do so to survive. When a new tool is championed or recommended, the first things the people I work with do, is go to GitHub and have a look at the source code. Is it scalable? Is the code base well written? The days of having one vendor or knowing only one technology with closed source code are gone, such vendors are actually treated with suspicion. It's not open source? What bad code are they actually hiding? Vendors all need to adapt to open source to survive and on the flip side companies need to make business decisions based on process and start becoming completely vendor and tools agnostic. Easier said than done, but 2016 is a good time to start if you haven't already, we need to start seeing vendors or tools as a facilitator of processes and not the dictator of process. The worth IT staff bring to companies is first and foremost engineering expertise and problem solving skills, not tools knowledge so please don't make yourself a one trick pony. Instead challenge everything, build new skills and make yourself a better engineer.