Screaming Penguin - Source Does Matter

Mirleid has an absolutely stellar treatise on enterprise software development over at K5 today. For the most part, I agree 110% with everthing he says. However, I do want to quibble with one point:

This is where things start getting hairy. Let's assume that, after examining your requirements, you decided that what you need is a system running on Solaris targeted at a J2EE-based execution platform. Well, writing EJBs (and doing it properly) is not something that anybody can do and is a skill that is hard to find (contrary to what most people posting CVs on the job sites would have you believe; and, yes, there's a bit more to J2EE than writing JSPs). So, you decide that you need to create some infrastructure code that will be used by the developers employed to write the system: this infrastructure code will materialize a number of patterns and coding guidelines aimed at "dumbing down" J2EE and thus making it possible to employ people that only know J2SE. Furthermore, creating this piece of infrastructure will ensure that there is a consistent "theme" to the code produced, making it simpler to code review and debug (or so you hope). It should also have a beneficial effect on the maintenance of the system, since the code that comprises it will fit a particular pattern that should be well documented (if not simple to understand).
Obviously, there is a flip side:

* Developers will start complaining almost instantly: this piece of infrastructure will necessarily restrict what they can do, and developers do not like to be restricted. If you hired consultants from the Big 5, their expectation is that, by being staffed to your project, they will acquire J2EE coding skills, which your infrastructure is preventing them from doing.
* By its very nature, your infrastructure piece will introduce overhead. This overhead means that there's less time for business logic to execute if SLAs are to be achieved, which leads to more complaining from the developers, because infrastructure is preventing them from delivering to spec. Overall, you are effectively slowing the system down by adding infrastructure.

While there is definitely a truth to what he is saying, I think there is a big catch to this and one that I am grappling with on my current job.

The large J2EE/SOAP infrastructure we have was built by someone who really really wanted to build their own app server. There is literally so much infrastructure code that surrounds an application that does... well, basically nothing, that it is much harder to maintain than if it were just a straightforward EJB app with SOAP exposure. Especially when you are in a world of rotating contractors, building the app too much with your infrastructure code means that anyone who comes on the project has to learn about your way of building apps. While "true" J2EE people might be rare, there is a 0% chance of finding a new contractor who knows how your stuff is built.

Right now I am working on specs for our next-gen app stucture, and I am really going in 100% the opposite direction. Much more POJO focused, and much easier to deploy. While I am working on new "infrastructure" code, I am trying to keep the scope as narrow as possible, and trying to work within standards. For instance, abstracting SOAP operations like attachement processing and authentication so we aren't tied to a particular SOAP container. I grapple with this, but I think it can be done in a way that doesn't leave an JAX-RPC or Axis person in the dark looking at it. I am also taking our internal SSO system and wrapping it in a JAAS provider with an easy way to extract the JAAS info out of the SOAP/Servlet/WSSE container. No, the average Java flunky doesn't know JAAS right now, but it is a well documented spec and that means if someone needs to get something done, there are a slew of tutorials on java.sun.com and onjava.com to get them rolling without having a huge base of internal docs for them to pour over.

Now, I am going another way and putting together a template project that is kind of "Web Services in 4 Easy Steps for the Moron" that does have as one of its user demographics some RPG coders who are getting re-tasked to Java. However, it is still built around the core J2EE Blueprints and while there are some scripts and instructions to help people along, it should look completely foreign to anyone who has done J2EE or Web Service work in the past.

In short, I see the "Developer Resistance" part, from my perspective, as not being so much about "I was promised I would learn J2EE here" as much as "I damned well know J2EE, why should I spend a month learning your crap."

Now Jim takes issue with the whole idea of design elegance. I see his point in my current world, but I think there is one other thing that is missing from the Rubicon piece and that is "Design" doesn't mean using every textbook whatever. Yes, good design starts at the class and method level. And god knows that just because you have every catchphrase framework and programming technique available too you doesn't mean you should use them. God also knows that there is such a thing as "design pattern abuse." Design is, at it's core, about making your software approachable. I am not sure that has much to do with language, as it does with the people designing it and moreover implementing the little bits.