First of all, please feel free of correct me not only technically but also linguistically, this is part of my English training :) If you can read Spanish you might prefer the Spanish version.

One year and a half ago I begun what has been my most complex, important and interesting professional experience: improving software development technique at an organization. This is a good time to look backwards.

I'll do it within four chapters:
I: current (one year an a half ago) situation study.
II: altertatives selection.
III: solution deployment.
IV: conclusions.

0. Precedents

I had been working with J2EE technologies, both profesionally and at home. I had previously done some things with PHP, and I liked to be up-to-date at industry innovations (RoR, Python...), altough I couldn't devote time in depth. Everything I did was, more or less, for decision taking management applications (I can't talk on real-time systems or high technology electronics, sorry).
From this experience I build up some axioms that I use to suppose as certain (altough when you're in computing you know the only right answer is 'it depends'):
  • Layer separation is a Good Thing:
    • There must be a dumb data access layer, decisionless, just to communicate with the database. It should essentially have just 4 CRUD methods.
    • The bussiness rules layer, above data, under presentation, is where you code specifications rules, from application data flow to data control ("who can see/edit what when").
    • Dependencies goes downwards, data, upwards.
  • Don't Repeat Yourself (DRY).
    • Corolary: don't cut'n'paste.
  • If you can choose, PHP, RoR or similar for small applications. For complex applications, J2EE.
    • Please don't begin a flamewar :) Yes, I know you can do far better things with other languages. Nevertheless, with Java you have great tools, great documentation, great libraries... and it's easier to control if you have to manage many people. Yes, of course, 4 great Python programmers will do a far better app that 10 mediocre Java ones, but this wasn't my case, you know what I mean ;).
  • Writing Java snippets at JSPs is bad.
  • Ajax is A Good Thing. If you do it by hand it might be good, but it's much better if a library provides you it..
    • Corolary: ajaxifying data is (probably) more efficient (from a networking point of view), ajaxifying interface is (probably) more productive (from a project manager point of view).
I. Current Situation Study

It was late 2oo6. Struts (Action, 1) begun feeling old, and 'Ajax' was the term you should say at an interview if you wanted to catch the attention. JSF already had its bulletproof bad health, just like now. A myriad of web frameworks (Spring Web, Wicket, Web Works, Tapestry...) waited its actual death to begin bragging. Microsoft, after his war against Sun, had published .NET, and every manager question was J2EE oe .NET?. Dojo was The Javascript Library, with his "no documentation at all" (or "document just a little, badly...) policy. If you wanted to keep a geek conversation, you had to know how cool RoR was, or that Google had broken every convention with GWT.

When I got to the new company I found a situation... well... uncommon. The whole World tried optimizing productivity and improving product quality with Java libraries, but they were developing with plain old servlets plus JSP, with embedded SQL... We belonged to another company (lets call it 'the supercompany') who imposed some other problems:
  • Old IDE:
    • Bad CVS client. It was no problem for the supercompany because they held the code at shared folders (sad but true), but it was for us, forcing us to use an external application.
    • Development on a different server, not the same as the production one.
  • Propietary server, badly documented.
  • In-house developed framework:
    • Classes generating HTML (forcing us to do things like new DropDown() at jsps).
    • One layer design, even with SQL at JSPs.
    • Wrappers for existing classes (we couldn't even access the actual Connection object).
    • Unavailability of source code.
    • Outdated documentation.
    • No standard library, not even Log4J or any other logging system.
    • Undocumented, hidden dependency on session variables.
    • Internet Explorer only.
This restrictions had led to many antipatterns:
  • Tons of repeated code.
  • Javascript only form validation.
After doing a first application "the old way" I was given a chance of doing a brand new design, a new arquitecture, a new framework.