I've also met bright people, mostly coders, who have told me they adore complexity. Even one young man who advocated hyper compact self-modifying code.
Don't we all do that to some degree? There isn't a fixed drop off point for "too much complexity" that's fit for everyone. Consider programming languages, are APL or Prolog "wrong"? Or, compared to something like Oberon, are Ruby, Python and Java?
You're implying that APL is complicated. It isn't. It was designed for regularity and simplicity. Iverson and his group worked on that for 7 or 8 years (can you imagine!) before they began implementing it, and what they came up with remains one of the great high water marks of software design.
This brings out a problem with the OP and the discussion. We readily dismiss things as complicated that are merely unfamiliar. The converse is also true: we don't see complexity once we've become habituated to it. And we become habituated surprisingly quickly.
So how do we distinguish between complexity and unfamiliarity? Without some reliable distinction, this is all in the eye of the beholder.
I think you're throwing out the baby with the bath water. The fact that unfamiliarity can be mistaken for complexity does not mean that complexity is impossible to recognize or avoid.
There are some cases where you can, for example, radically simplify a complex algorithm by using an unfamiliar toolkit (Feynman diagrams, Lisp, etc.) but there are also cases where a solution is obviously more complex than it needs to be even within its existing framework.
Oh, I don't claim that complexity is impossible to recognize. It's really important to do so. But how?
Most judgments of complexity we currently make have a lot to do with familiarity. (Is the 40-line spreadsheet program at http://www.nsl.com/k/s/s.k complicated or simple?) You assume something similar when you say "obviously more complex than it needs to be". When is complexity obvious? When it exceeds what we habitually consider ok.
What we really need is an objective measurement. Do we have one? We sort of do, insofar as the research on this seems to point in one direction: shorter programs are simpler. That doesn't answer every question - you still need a way of measuring program length and defining what a program is - but it's the beginning of an objective answer.
For evaluating a refactoring or using a library/framework, you can compare the number of statements that would be used to add a given feature before vs. after the refactoring.
What's harder is to evaluate the effect of adopting a certain pattern or framework will have on the cost of future refactorings. I don't think people do even a back of the envelope estimation of even just the first number. The number of statements put in can probably be used to estimate the cost in man hours.
My preference would be to put it in when it pays for itself (i.e. makes the code smaller) and not before. Otherwise it's too easy to fall victim to one's own spin.
Good point. There are multiple axises of difficulty. Amount of things to remember, interconnectedness of said things, potential drawbacks, unfamiliarity, idioms etc.
Lots of musicians go through a stage where they are trying to see what they are capable of and make music as involved/complicated/ornate as possible. Many of them mature into musicians who try to find a few elements that work together.
And then there are others that try to come up with a highly complex Magnum Opus. Punk is simpler than prog rock, does that make King Crimson listeners bad people?
There (probably) are areas at the extreme ends of the spectrum where things are too complex/simple, but there's a big range in between that might do it for certain people. I don't believe that just liking some form of complexity is objectively bad. It's not all just complexity for complexity's sake.
And then there are others that try to come up with a highly complex Magnum Opus.
In terms of artistic works that people still actively experience, the tendency is for the classics to be simpler works. Complex works tend to be classics in the Mark Twain sense.
...does that make King Crimson listeners bad people?...I don't believe that just liking some form of complexity is objectively bad. It's not all just complexity for complexity's sake.
I don't believe that just liking some form of complexity is objectively bad either, in general. In the case of coding projects, though, I have to note that the scarcest bandwidth is often reducing team lead bandwidth. Exactly what this means is highly contextual. The tricky part here is in the "but no simpler" phrase of the Einstein quote.
You might say that I like minimalism because I'm lazy. Minimalist cuisine means fewer ingredients to prep, less cleaning later. Minimalist syntax means fewer things to keep track of and lower barriers to tool-smithing. I don't think that makes me a bad person either. The question to ask is, what is the cost/benefit now, and what's the cost of changing your mind? Sometimes the more complicated system reduces the latter cost. YMMV
Sure, teams complicated the complexity issue. Which is why things like Java are so popular, where the moving parts of the language itself are few enough.
It's jam sessions all over again. Much easier if the basics of the musical form aren't too complicated (e.g. 12 bar blues) or everybody knows the same songs already (e.g. Irish folk). Getting a random bunch of people together for some Free Jazz is a bit harder.
Bach had some complicated, almost math-like themes, but is it really more complex than Wagnerian leitmotifs and huge orchestral settings or Schoenbergian modern music where the traditional score notation can't keep up anymore?
But yeah, the analogy is easy to abuse, due to the multitude of artistic styles, and active rebellion against the "mainstream". For every Piet Mondrian out there, you can find a Chuck Close.
Let me guess... they were addressing hypothetical scaling issues for a site with < 100 users? Instead of optimizing the conversion rate on their homepage and mailers?
