Trusting the documentation and what it means

I have often been told that I don't have experience in this software or that software. I use the word software to mean all the languages, frameworks and products that get created in the IT world.

Software industry is huge.

There are a number of software technologies that get created and popular from time to time.

You cannot possibly know all of them. Even worse often possibility of your exposure to them is dependent on the firm you work for, the client you work for and so on.

But I have never thought of this as a limitation because I believe in the software documentation that all come with. They have a purpose. They educate you. They inform you what it is capable of doing, what it can do under and what it will NOT do. The good ones will also come with information on what its limitations are.

This implies that I don't actually have to experience each one of them to be able to advise on it or make any other decisions about it.

The following incident has influenced this thought process.

I was client rep for a software transformation project. As is true for all transformation projects you do come up short sometimes or the results you produce are different from what the client expected. This was one such instance.

The client contended that the original software worked in a certain way. We said it did not.

A high power steering committee was given the responsibility to judge.

This was terrifying for more than one reason. I knew its documentation forwards and backwards and knew what it said about this particular capability.

The meeting started.

There was the usual back and forth with varying prior "experiences" being mentioned as proof of the original software's ability. It appeared that we were heading for a stalemate when one of the client's committee members suggested we actually try it. Right there in the meeting !

This was the moment of truth.

Well, if your guess was I came out top then you would be correct. The software did exactly what I said it would do. What I read it would do. What the software's own documentation said it would do.

I was proven correct.

The issue was resolved. We got our way. But most importantly I won their respect and trust.

But that is not the point of this blog. It strengthened my belief that knowing the software documentation to understand what the software can or cannot do is enough. It is not required to have worked on it to be able to make judgments about it. You can read the software's manual and claim that you will be able to work with it or even claim that you HAVE WORKED WITH IT.

Over the years this maxim has proven true over and over. So, this is my plea to all the decision makers.

When you consider the suitability of a software - check its manual

When you consider the suitability of a professional - check if the person is well versed with the documentation. Does he have the drive to learn from it?

You will see you will start making "more" correct decisions both with regards to the choice of software and with candidates.

What is your experience with software documentation? Have they proven life savers?