Friday, September 23, 2005

The Main Things for Software Projects


The preceding is a summary slide from a deck I am using to clarify my own approach to methodology. It is a synthesis of recommendations from the CHAOS report, Alistair Cockburn, and my own experience.
Essentially, I mapped out the lists of "main things," or critical success factors, provided by CHAOS and Mr. Cockburn, and also made my own list. Then I went through an exercise of correlating and consolidating. This is where I ended up.
I think this checklist provides a concise, strategic guide for improving a project's chance of success. More useful still would be individual guides that provide tactical guidance for each of these, probably mapped against key project variables (like Alistair's team size and safety). I'll get right on this in my free time.
I also think it would be interesting to check this list against other similar lists from other modern methodologies like RUP, XP, etc. Rhythm, presented to the DJUG by Brian Boelsterli, looks like an interesting framework that might also have similar factors to consider.

Friday, September 09, 2005

Rapid Prototyping and Development--Options

In this post, I continue my analysis of rapid prototyping for Java Web apps. I see a few essential ingredients necessary for rapid prototyping:

  1. Fast and simple development of pages and page flow: must be able to easily create pages, get parameters from a submission, do business stuff, go to the next page, and present dynamic data--without manually touching 12 different files.
  2. Automation of basic CRUD activities: Even in complex apps, so much code fits a basic CRUD template. It is extremely helpful to be able to automate the first cut at this, by specifying model information once in the database, the code, or a neutral spec.
  3. Quick develop/run cycles: If it takes 45 seconds to see a change to the width of a text field, rapid prototyping is in trouble.
  4. Extensibility: Whatever cool automatic stuff is done for us, we need to be able deviate from the happy path and customize stuff.
  5. Anything else I am missing?

Are there Java technologies that allow developers to skip the enterprise stuff initially, and add it in later with a little refactoring?

  • JSPs with code in the pages (or Velocity templates w/out the MVC, etc.): Good for 1 & 3, but ignores 2.
  • IDE / Graphical tools: E.g. Java Studio Creator (is there a comparable Eclipse plugin?).
  • Rife framework:
  • Trails framework:
  • Model Driven tools: I looked at AndroMDA a while back, and I don't remember it striking me as a tool for rapid prototyping. But it is probably worth another look. Since I started this post, I have come across Gorilla Logic, which looks very intriguing.

Are non-Java tools, e.g. Ruby/RAILs, that allow for development that is so inexpensive that we are willing to throw the prototype away?

  • RAILS claims a 10x productivity advantage over J2EE, and judging by their demo it is at least that. So even if Ruby CGI is insufficient for Enterprise requirements, you can create a throw-away that is worth the effort.

To Be Continued...

Rapid Prototyping and Development--Questions

I've been thinking again about rapid prototyping and RAD tools for Web development. Perhaps it is because I have been working with Enterprise apps for a few years, with their focus on hard-core non-functional requirements (security, scalability), but I don't see much going on anymore. It seems to me that J2EE, and the various Java frameworks, are so focused on robustness and maintainability that rapid prototyping is nearly impossible.

In the wild and whacky early days of Web development, it seemed that we got the functional requirements right, but then endured hell when our applications didn't perform or missed the mark on non-functional requirements. Why? Because we did very minimal requirements and immediately dived into scripting pages, essentially rapid prototyping. Now, as I see it, the Web world has inverted this situation: we have to do more requirements because it is more expensive to get working code in front of the user, but the technologies are more robust. I contend that, in general, it has become more difficult to get the functionality right, and that we now have applications that are often over-engineered.

I'd like to figure out how to re-introduce rapid prototyping into the realm of Java Web development. Here is what I think I need to figure out:
  • I see a few essential ingredients necessary for rapid prototyping: Fast and simple development of presentation code, automation of basic CRUD activities, and quick develop/run cycles. What else?
  • Are there Java technologies that allow developers to skip the enterprise stuff initially, and add it in later with a little refactoring?
  • Are non-Java tools, e.g. Ruby/RAILs, that allow for development that is so inexpensive that we are willing to throw it away?