Ignorance, I Tell You. It is All Ignorance

In the post Ignorance vs. Negligence, Ayende blows some steam off in regards to so-called "professionals" he's met along the way. You know -- those people with fancy titles who don't know jack and design some of the nightmares we see from time to time (go read his post, I'll wait -- I promise). I see this all the time:

• The senior security expert who recommended something which isn't supported by the platform.
• The senior architect who throws the system to hell by basing all the system on a clunky asynchronous solutions that should only be used by a tiny portion of the application.
• The geniuses who built this wonderful code generator that generated code with so many dependencies and singletons that made the solution unusable.
• The chief architect who created this wonderful performance hog, then kept poking around to make sure we don't fix it too much.
• The architect who partitioned a distributed solution based on functions -- so that each and every business process has visit go through all the tiers and components. The solution made the everything more complicated by few orders of magnitude (scale, synchronization, availability, performance what not).
• The architect who designed his own distributed transaction mechanism (basically duplicating COM+) ---naturally with less than satisfactory results...
• Etc.

Ayende says:

They all have a few things in common, they represent themselves as experts, senior, knowledgeable people. In all those cases, they have actively acted to harm the business they were working for, by action, inaction or misaction

I have no issue with people not knowing any better, but I do expect people that ought to know better to... actually do know better.

I don't think that this is negligence involved here -- I think all of these people want to do the right thing, they probably believe they are right. They were probably also pretty good at their jobs which is what got them to their current position.

What they didn't learn is to "know that they don't know". This is a hard lesson to learn. I think hope I learned my lesson after the first time I tried to distribute a (naive) solution I was so proud of. At least, in my case, I stayed around for enough time to both see the results and learn how to fix the problem.

Not staying around for enough time is one of the problems that causes this ignorance -- since starting out things usually look good enough and if by the time the problem rears its ugly head you are already in a new shiny job, they you don't know better.

Another problem that causes ignorance is not looking around and learning only from your experience. For instance, I am now interviewing a lot of people, and when I ask a question like "tell me about something interesting you recently read -- a book, an article, a blog uanything" -- I usually get blank stares. Few people tell me about an article they read that is related to a problem they had, and fewer yet tell me about something without a direct relation to their work. If you don't look beyond the keyboard you will never know better. Learning only from your mistakes can be problematic -- especially if we also consider the previous point (people don't stay around).

Ignorance is bliss they say, but ignorance has a lot to do with the crappy systems we see all around us and its one of the reasons writing software stays more of an art than a science or craft.

Posted by Arnon Rotem-Gal-Oz at 07:19 PM  Permalink