I Could Not Care Less What System You Use

This essay by Jeffrey Veen on why content management fails is right on the money. I will not repeat his main points, but I just want to make some quick comments.

I cannot count the number of times that I have engaged in conversations about the merits of various content managements systems. Does it matter? Perhap it matters, but what matters more is to plan how you are going to manage content in the enterprise. Planning includes defining process and workflow, and determining how to staff positions on a content management team. Planning may even invlove defining what you mean by content. For example, there could by FAQs, press releases, internal news, internal blogs, training materials, policies and procedures, staff directories, on-line threaded discussions and so on.

In the begining, it does not matter which system you use. It matters that you can plan the work and establish a budget. Then, choose the system while mapping it to your budget and needs. I have seen many content management projects fail because they were too open-ended, or because they were incorrectly defined. I was once involved in a major initiative by a large fortune 100 company that spent tens of millions of dollars and got nowhere.

Sometimes, I talk to developers who are working on projects that they call ‘implementations’: as in, we are implementing a content management solution using Hummingbird. I will often press these developers to explain the problem they are trying to solve. After all, how can you say that you are implementing a solution if you cannot state the problem? The developers will often say that they need a system that can retrieve both formatted and unformatted content. They will also pepper the discussion with all the right catch phrases and acronyms: XML, faceted metadata, fulltext indexing, and many others.

However, it is obvious to me that the developers are solving their own problems first. It is MY problem as a developer to find a way to search both structured and unstructured content, but users do not care. The user wants to find a press release, a biographical reference or a piece of correspondence. When these gigantic content management projects launch, the users do not like them, or they feel intimidated by them, or they find themselves without the team structures and processes to use the solution. The project fails, and the developers blame the users.

So, ok – I ended up repeating Jeffrey Veen’s main points. I couldn’t help myself.

NOTE: To be fair, there are cases when large organizations, like the Provincial government of Ontario, tries to provide a solution for extremely large groups of users in multiple business units. Sometimes, the idea is: build it and they will come. A lot of good thinking goes into these projects, but I cannot help but thinking that the task is too big. Time will tell. Personally, I do not think one size fits all.

Being Lied to by Tech Support

Tech support is a difficult and thankless job. Having said that, most people hate dealing with tech support. Non-technical people sometimes blame themselves for this – they feel stupid, and assume that the problem originates with then. As a person who is more technically knowledgeable than the average person, I must make the following report: knowing something about technology does not make interacting with tech support any easier.

Case in point: I have been having difficulties browsing. Some web sites that I like to visit have not been accessible to me. At first, I thought the sites themselves were down, but then the problems just became too frequent. My first guess was that there was a DNS problem. (Notes for the uninitiated: computers that are connected to the Internet all have unique numeric addresses that function much like phone numbers. However, these numbers are not easy for us to use; therefore, the Internet relies on a special network of domain name servers to convert URLS such as http://jimcassidy.ca to Internet addresses such as 66.179.181.182.)

Without a domain name server, it would be impossible for you reach my site by typing http://jimcassidy.ca in the address bar of your browser. Instead, you would need to know the IP address. You can discover the IP address of any site by using this tool: dnswatch site. By using this service, I found the sites I could not reach were reachable using the IP address – seems like a DNS problem to me.

You would think it would be easy to get a resolution from Bell Sympatico tech support. Think again. I do not want to fault individuals, but here is what happened. I send two emails outlining the problem, and I received no reply. Then, I contacted a representative who could not help me beyond suggesting that I empty my cache. The representative was not willing to stick with me until the problem was solved, but she did thank me for choosing Bell Sympatico.

Today, I contacted a tech support person who was more knowledgeable, and she walked me through the process of recreating my connection on my Windows machine. DHCP was not working on my Windows machine, and she helped address this problem. So far so good.

Of course, I did explain that 90% of the time I am running Linux and I use a router. When I asked her if other people were having the same problem navigating to sites using URLs, she cut the call short and closed my ticket. Again, she had no suggestions, and she was not aware of the problem.

I get the feeling that Bell Sympatico is not prepared to admit that there is a problem. I also get the feeling that Bell Sympatico has instituted a policy of not opening tickets for this issue. Although I asked directly if the two representatives were aware of DNS problems, neither admitted that they had heard of any such problem. The fact that I was able to find multiple references to a Sympatico DNS problem on the Internet leaves me feeling that I was being lied too. As both representatives told me, the call may be monitored – perhaps they were instructed not to admit to the problem.

Sympatico did offer to send me a new and more powerful modem for free if I agreed to continue my contract for at least another year – otherwise, there would be a fee of about $75. I see that as an attempt to lock me in, especially since I was considering finding another supplier.

Being knowledgeable has not helped me. I feel that I was not listened to, and that Sympatico could not admit that there was a problem. In the end, I searched the web for a solution to the problem. Many other people are having the same problem with Sympatico. Basically, I am now bypassing the Sympatico DNS servers and using a public DNS server at 4.2.2.1. Problem solved.

Still, I get the same feeling that many people get: tech support is not there to help me. In the end, tech support represents and serves the company. No honest attempt was made to help me with my main problem, and, frankly, no attempt was made to be honest. I cannot believe that these two representatives are unaware of the problem. I am unimpressed by the fact that my two emails received no reply. I will stay with Sympatico because I am lazy, but the company has lost my loyalty. I am ripe for the picking if Rogers, or any other supplier, wants to call with a special offer.

Ask The Dumb Questions

Programmers have a reputation for being smart. I am not sure that is always true, but I do know that that stupid programmers seem to think they are fantastically smart. They love complexity, and tend to look down on anything simple. I tend to like simple things. I won’t say that this means I am smart, but simplicity and elegance often go together. Just because it is easy to understand does not mean it was easy to conceive of.

I ran across the following article entitled “Why Good Programmers are Lazy and Dumb”, and I found it interesting. This entry received several comments. My favorite was: “I r lazy.”

My years of programming have shown me that smart people can become their own enemies. For example, I cannot count the number of times I have assigned work to a programmer only to find him sitting there later in the day trying to fugure out why his code does not work. Long after it is obvious that it is time to come up with an alternative solution, the programmer will try to find out why his solution does not work – after all, it SHOULD work. I have to remind the programmer that his job is to provide a working solution – not to understand why a solution does not work. Smart people can become side tracked by their own curiosity.

We all go through a phase of thinking that we are smart. I can remember spending hours ensuring that my code on a particular project was reusable, only to realize years later that I had never reused it and never would.

It turns out that the real skill is knowing when to make code reusable not knowing how to make it reusable. Many programmers think they are smart when they know how to do something – knowing how is only the beginning. Sometimes it pays to ask the stupid questions:

1. Is this framework really necessary?
2. Will I ever use this code again?
3. Am I working to hard to do something that should really be easy?
4. Does doing things the so-called smart way always have to be so hard?