We’ve all known the person that believed they knew everything there was to know about topic X. In IT this person is so commonplace that I have wondered if there isn’t an advanced cloning device that spits them out on a daily basis. While this self confidence (or bravado, whichever) in the right individual, at the right time, has done some amazing things in world history and specifically in the history of computer science, most of the time it is merely annoying. When any attempt is made to explain even what the individual doesn’t know, they tend to walk away thinking you’re too dumb to understand. That passes annoying and enters dangerous. Not dangerous in the sense that someone is going to get hurt, but dangerous in the sense that this person with incomplete knowledge and overweening arrogance is working on your IT systems. Without the complete picture.
In my experience, the in-your-face “I know everything” person rarely does… Though I knew a really annoying UDB guy who really did know everything. He could do just about anything with UDB, if you could convince him it was important. He saved my project timelines more than once, because I sat through his “you’re an idiot” tirades to get him to do what needed doing. And everything he did was right when he was done. But he is the exception. I have far more anecdotes of people who had a chip on their shoulder and it wasn’t warranted. Including being lunged at in an interview I was conducting when the interviewee got a question wrong and I tried to explain why to him. I didn’t hire that guy ;-).
In IT – in business in general - it really isn’t acceptable to be this person. And yet they seem to exist at every level.
For the last few nights I have been working to get an open source library working in my environment. Normally there is nothing to this process when Java is the language – that is one of its strengths, but there were several sticky problems with this one, starting with corrupt jar files, and ending with incoherent documentation. In the end, I decided that there were other ways to tackle this problem and I had wasted enough time on the library at hand. Part of my decision absolutely was the mentality of the developers on the project. One person had posted to them “I must use Eclipse, because that is the standard for my team, and X isn’t working”. Guess what several of the developers answered? “Don’t use Eclipse, it’s stupid” (paraphrased because they’re amalgamated). NOT. HELPFUL. This poor guy was left on his own because their new “environment of the week” was all they cared about, and the vast bulk of Java developers still using Eclipse were “stupid”.
You see the same types of answers – even from commercial products – about which browser you’re using. Even today.
It’s a decade into the 21st century, browser wars hurt your organization/project, do not let your people tell enterprise customers to change toolsets, support them or don’t.
Most enterprises want a few things from products they use. Provide them, and whether open source or commercial product, they’ll use your tool when it solves their problem.
Now, I get the fact that many open source projects don’t care if they’re enterprise class, but a lot want users, and are making projects most useful in the enterprise. And these points have been known forever. I didn’t invent them, they’re what enterprises have looked for in the bulk of their projects for a very long time.
So one is forced to wonder, why are both commercial and open source products still failing on these points so often?
It’s easier to see how/why in open source. No matter how much I’d like to argue it, as a geek who also writes, the type of person who is qualified and motivated to work on an open source project is often not the best choice for talking to users and helping them understand… And yet they are the ones doing it. For developer oriented projects it gets worse, because the early adopters are often not patient with people who don’t “figure it out”, amplifying the issue. Linux is the poster child of oss projects that survived this stage of life. So many people were out there acting like you were an idiot if you couldn’t figure out X or Y or Z, and had no concern at all that their attitude turned more people away from Linux than the initial learning curve did. For every Linux though, there are thousands of abandoned projects. Recruit someone on your project who is technically competent, but can write. Get them involved, have them do the documentation. Please. For your sake and all your potential users’ sake. Better, get them to gather ideas/plans for the future and turn them into something digestible. And get them out on places like StackOverflow to answer questions. Essentially, bring in an evangelist.
In commercial products (including the OSS/commercial hybrids) it is a little more complex. Companies have to care about income streams and how to be successful. Money and resources must be funneled toward that end, and that sometimes means product X or Y or Z doesn’t have the above, because there just isn’t time or money to invest in them. I guess my recommendation to enterprises in that case would be to look for another supplier. It’s tough to walk away from a great solution because it doesn’t have some of the above points, but if the “great solution” breaks and there isn’t decent support for it, well, then it’s not such a great solution. The same is true of the other items in the list. Lacking them is a sign the product you’re considering is not ready for enterprise level use.
Just my thoughts on the topic. In the end, it’s your enterprise network/dev environment/apps, you absolutely should do what’s right for your environment. And yeah, I have once or twice chosen projects/products in the enterprise that were missing one or more of these items, either because the options were limited, or they were so good at what they did that I figured they’d catch up with the other stuff long before they burned out.