title: A more agile alternative to Java EE
body: <p>In a nutshell, I'm trying to find a process/technology stack for web applications development, that is easy/fast/flexible to prototype, but has a clear upgrade path to a robust production platform.</p>
  
  <p>I apologize for a lengthy description below, but the problem is between the tech and the process and I can't find any easy/short way to express it. And yes I read "Good Subjective, Bad Subjective" article.</p>
  
  <p>Currently we are using Java EE with all the blows and whistles (agile, continuous integration, issue tracking, unit testing, hibernate/spring/stripes/jquery stack ...). We also use a flexible project definition/analysis process with feature gathering in parallel with GUI mockups (kudos to Balsamiq Mockups) creation and later HTML static pages prototype. During the development, we do frequent intermediate builds with client reviews. So once we get to the testing phase the functionality is 90% on target and all is needed is some bugfixing and the final robustness polish.</p>
  
  <p>For our traditional clients ie banks and pharmaceuticals, the above process/technology stack works like a charm.</p>
  
  <p>Lately though, we are developing for the internet startups. In this case the process is quite different. We start with some basic mockups, then the first very raw prototype is made (lots of static pages + some basic functionality to cover the core scenarios). Then we start developing the full blown application.</p>
  
  <p><strong>Critical step here!</strong> When the application goes public, the marketing/business guys receive the feedback from the early birds, observe competition, they make their conclusions and want to change the application. <strong>A LOT!</strong>
  But at this point we are not in the prototype mode any more, we have a nice robust, production quality Java EE application with hundreds of unit test built in. We can evolve it, but it certainly is neither easy nor agile.</p>
  
  <p>1) On the process side, we tried to nail down the spec with all the visual and formal tools available, but in vain; nobody is able to fix the spec before the market speaks.</p>
  
  <p>2) We tried more "flexible" environments like RubyOnRails and PHP.</p>
  
  <p>2.a) For the production grade quality, those still seem a little bit week compared to Java EE (yes, I know that some of the most important services/apps are written in PHP)</p>
  
  <p>2.b) If we use them in "flexible" way, they are great for prototyping, but then we obtain the code that is difficult to rise to the production quality.</p>
  
  <p>2.c) If we implement all the best practices (layering, unit testing ...), the complexity becomes comparable to the standard Java EE's complexity that we already have.</p>
  
  <p>3) When the app goes live, it has to be polished and robust, so an easy to make prototype is no option.</p>
  
  <p>4) If we propose to make a throwaway prototype, the client refuses to see it as a throwaway and asks to bring it to production quality (not willing to pay the start-from-scratch development).</p>
  
  <p>So basically, we are putting "quality" (intending structure, robustness) too early in the process, when it is not needed and when it stays in the way of change and flexibility.</p>
  
  <p>Any ideas?</p>