Pragmatism and Idealism in Software Development
I was involved in an interesting discussion this past autumn with a very pragmatic programmer. He was making a point (which Udi might agree with) about how business logic doesn't belong in the code. He presented a set of complex business rules which needed to change frequently. After he presented the problem and asked for ideas I suggested a rules system. He shot it down, politely, and went on to describe a micro-language solution (which was a rules system anyway, of a sort).
I say 'of a sort' as there was no mechanism for describing rules, just sequences of actions -- you matched one and off you went. It was a very nice, elegant, little solution. Later I asked why my rules engine suggestion had been shot down and it was pointed out that a six-figure business rule engine for this would have been gross overkill -- particularly when he had a neat little solution. I bought this as his solution was quite neat, though a six figure rules engine isn't what I had in mind.
This is a picture perfect of example of worse-is-better, pragmatism, etc. So is HTML, Java, RSS, etc. None of these things are particularly elegant (okay, the micro-language coded action sequence was a pretty spiffy solution for his problem) -- but they all work well. Pragmatism is on the rise -- do what works, don't make it any more complex than need be, etc.
This just doesn't sit with a lot of people. Pretend the situation is black and white -- pragmatists on one end of a scale, and idealists on the other. I fall (flat) into the idealist camp (in terms of what I value in code, not necesarily the quality of my code ;-). It bothers me when faced with [cheap | fast | correct] and correct is not the one selected. Sure, I deal with it -- you have to in order to write software for a living -- but I leave little apologies in cvs logs, comments, bug reports, etc.
The minor hullabaloo about ioc containers is a great example of this. Avalon was a brilliant idea, and people ran with it. Now no one can quite decide what Avalon is, so people are taking the ideas and running with them elsewhere. Pico is fairly complex (that is downright funny to say) but a type 3 container is just wonderfully more elegant than a type 2 container, even if the type 2 container is more pragmatic most of the time (as it gets around varying component designs better, typically) The ideas, goals, etc are the same, but the mechanism of one design is just nicer -- and no amount of code (actually, that is a bad idea as needing more code is a sure sign of less elegance) or support for adapting other complex designs (running EJB's in a type 2 container a la Hivemind) will get around that. Sure, type 2 is more practical ofttimes, but it doesn't mean I have to prefer it.
All too often, however, a practical idea taken to an extreme and vast amounts of complexity are used to implement an inelegant solution. If something is big, complex, powerful, and flexible it is frequently presumed that the complexity is necesary for the flexibility. It seems reasonable that as flexibilty increases so will complexity. You could describe a kind of calculus of development where a low differential between the flexibility and complexity curve is an important metric (except how could you ever get a meaningful measurement?)
Sophistication is a good idea for describing elegant complex things, I think. You may describe somebody as complicated, or sophisticated -- but you mean that they are complex. A sophisticated complexity is one that enthralls you, a complicated complexity is one that scares you. Sophisticated tools enable you, complicated tools create job security. Even better, sophistication in software may well describe simple things that enable massive complexity.