Complexity, FUD, and Evolution

Code complexity is one of those topics that kind of makes me cringe when I think about it. Not necessarily because I fear complex code or that I like it - that's too easy to talk about - but more so because it's an easy way to write something off if you don't understand it.

I've come across a lot of people who, when encountered with something that they haven't seen or haven't fully explored, they slap the complicated sticker on it and keep moving. Think about it; it's not that uncommon. When you first look at something that is, in some way, different than what you're used to and you have very little transferable knowledge, it's easy to get discouraged and want to fall back to known territory. I do that all the time. Sometimes, I catch myself, but other times, I fall victim to my own lack of understanding.

For example, the first time I worked with Oracle (I mean really worked with it as a DBA), I was completely baffled by the way certain things worked. Everything seemed so convoluted. After time, most of it made sense, but I had to invest the time and energy in learning about it before it seemed, at all, tractable.[1]

Commonly, I see this kind of FUD (because that's exactly what it is - fear, uncertainty, and doubt) when I discuss things like design patterns and system architecture with people that don't have a lot of experience or who haven't invested a lot of time expanding their view of these subjects. One case that comes to mind (and that is short enough to explain here) is when I explained what the Singleton pattern was to someone and why it made sense in the particular context. The developer looked at me like I hadn't written a lick of code in my life.

Why do I need to write a method to provide access to the static variable when I can just make it public? This single-whatever-thing just bloats the code and slows things down - accessing a public static variable is faster than calling a method.

Honestly, I didn't know what to say. I explained things like encapsulation and centralized construction. I talked about all the things I've never had to actually argue in favor of (this was some time ago; I've since had this exact and many similar discussions) but it ultimately fell on... well, I'm not sure; just normal ears, I guess.

The person (and other people, since) that made this argument wasn't / weren't dumb, nor were they inexperienced. What they were was overly conditioned to think about things in such a lopsided way they had closed themselves off to learning about anything deviating from the conventional theory they had developed. And, the entire development team would lose out, dealing with code that was slightly, but not catastrophically, harder to maintain.

This mentality is contradictory to what we do. What we do is not static. Programming practices evolve and, hopefully, we keep the good stuff while incorporating new ideas and technologies. I'll eat my own dog food on this one, too; if we find things better than agile development, software design patterns, and the like, I, too, will integrate those ideas. It will happen. The above example (i.e. the infamous singleton story) is indicative of dogma, more so than a science (with my apologies to the mathematicians).

[1] - Note that I do believe that, while I understand why Oracle does a lot of the things it does, I don't believe it necessarily does those things in the best (easiest to understand, most useful, etc.) ways. I say that having worked with Oracle in a development, DBA, and system administration capacity from versions 7.x through 10g, inclusive. Your mileage may vary.