Ignorance I tell you, it is all ignorance.

I was poking around my old blog (rgoarchitects.com) and I found this post from 2007 which I think is worth re-iterating:

In a post called “Ignorance vs. Negligence“, Ayende blows some steam off on some of the so called “professionals” that he met along the way. You know …those with a fancy title that don’t know jack and design some of the nightmares we see from time to time. I’ve seen this phenomena in a lot of projects I consulted/reviewed:

• The senior security expert who recommended something which isn’t supported by the platform
• The senior architect who throw the system down 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 that built this wonderful code generator that generated code with so many dependencies and singletons that made the solution unusable
• The chief architect that created this wonderful performance hog, and then kept poking around to make sure we don’t fix it too much.
• The architect that 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 that 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 wanted to do the right thing, they probably believed they were right. They were probably also pretty good at their past jobs that led them to the 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. Well, at least, I stayed around for enough time to both see the results and learn how to fix the problem.
I think not staying around for enough time is one of reasons for this ignorance – since on the onset things usually look good enough and seem to work. If by the time the problem rears its ugly head you’ve already moved on to a new shiny job, you’d missed the opportunity to learn form your mistakes.

Another cause for 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 anything” – I usually get blank stares. Few people tell me about an article they read that is related to a problem they had, and fewer still 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, maybe so – but I think 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.

illustration by parl

Related posts:

Evolving Architectures – Part V – Leaps SOA – Contracts, Events and ownership SOA Patterns : Composite Frontend (PDF)