IMO

I am working on a Webinar presentation that I will be holding for MySQL and Covalent about the LAMP architecture. The more I work on it, the more I'm reminded that we seem to be at a point where most technical arguments align along one concept: simple vs. complex. Look at the current favorites: REST vs SOAP ("traditional" Web Services); LAMP vs. J2EE; RoR vs. Everybody Else. Then look at the current "hot" technologies, which run the gamut from AJAX to SOA and ESB. Again, we see the range from simple to complex. And, of course, the old reasons and arguments are still being bantered about: "Simple lacks the power and capability" and "Complex problems require complex solutions." And it's also interesting that when a simple technology takes hold of the community and becomes "interesting" and hot, almost immediately a complex technology (usually a "framework") pops up as well. Like nature, the community must deplore magnetic monopoles. What is going on here? I admit that, at heart, I am a simplist. I value elegant and simple solutions over more complex ones. I also value frameworks and technologies that have those same standards as well. IMO, there are no problems that cannot be reduced to a manageable number of simple constructs. I would guess that most developers and software architects also feel the same way, so why is there such a prevalent prejudice against simple and elegant technology. It's almost as if there is a subset of people who feel that such tools as LAMP or RoR are "toys" and not "worthy" to be considered robust, enterprise solutions. I wonder if part of it is simply to protect themselves, and by fostering complex solutions, they protect themselves and their livelihood. Going by the stories and blogs about various interview "techniques" people have had to suffer through, it certainly feels like it. For example, some of the hoops that candidates are required to jump through seem almost sadistic to me, and certainly do not provide any real clues on how good they are. I want people who can design, who can abstract. I really don't care a fig if they know the full semantics of every function or method call of a particular language set. That's information that you can grab out of a book in a minute. Programming is not memorization, it's crafting. It's art. "Hurry up Mozart, you have 3 minutes to compose a waltz." But those interview horror stories do make sense when seen in the light of the matra "we must perpetuate the complexity of implementation." The desire is not to "get to know" the candidate, but to emphasize how smart the interviewer is, and how complexity is valued, not simplicity. I've said before that programming languages and frameworks are tools, and that you choose the right one for the job at hand. Not everything requires complex solutions, in fact I would guess that 97% don't. Choosing and using a complex technology stack doesn't automatically make your application "advanced" or "enterprise ready" or even "good." It just makes it complex. True Story: Several years ago at NASA, a circuit designer friend was given the task of designing a device called the Essential Power Transfer Unit, which was supposed to transfer electrical power from one spacecraft system to another. There were a whole bunch of specifications, and lots of concerns about the costs associated with it, and the hit to the schedule to design and build it. He used a wire. It worked perfectly. Use a wire.