Quote of the month

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Martin Fowler, "Refactoring: Improving the Design of Existing Code"

Language "wars"

I'ts me or we are at "war" again?
As the old history goes, in the nineties, OO Warlocks fought each other from their towers, everyone claiming to have The Methodology, until some of they settled for the "Unified Philosopher Stone" or something like that... (I always thought it was strange that the outcome of a methodology war as a notation, but I digress)
After that, came the agile jihad, trying to burn the non-believers in the stake, all in the name of the eXtremellyPurity religion, causing great havoc in the process world (and every process guru claimed "I'm agile too!", probably to satisfy the angry mob... but agile waterfall got burned anyway). Is funny now how many experts now say "XP is very good, but if you do < insert your favorite common sense practice >, is even better!"

And now, the languages!
Well, is not really a war, I guess is more like in the OO-java-roman.net empire, encounters with the Rubyites or the functional programming tribes and similars(the Haskells, Lisperers, or Schemitas) are getting more common... their hordes always roamed in far away places, but they are getting closer and closer. Even the habitants of island of JavasCriptya turned out to be part of the FP tribes! Granted, the Enterprisey temples, aqueducts, and coliseums will not easily fall or be overrun by them, but I guess some interesting things will happen. Maybe with an unifying Domain Driven lingua franca we can get the best of each other, because frankly, Java (the kingdom of thousands frameworks) is hard
I forgot to mention the mythical lands of Translathia, where their habitants write using symbols instead of words, and through their magic, they materialize what they just described... they have all their stuff decorated with their hieroglyphs. Mythical as it sounds, I happen to know two respected sages from that land...


Now, seriously... I'm seeing a lot of noise/cool-stuff from the FP camp, probably thanks to the concepts introduced by Ruby, and I think it would be good to learn a new paradigm.

JSF code snippet: integrating JSF pages into a plain old JSP

A simple way to include a JSF page into a bigger JSP (sure there's other ways, but this one is easy):
the JSF page must be a subview:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<f:subview id="myJSFSubview">
.....
</f:subview>

The tricky part is how to include it in the JSP, in a way that is independent of the main JSP. But you just need to include like this:

<% pageContext.include("myJSFpage.jsf"); %>

Project (and people) over Process

Thinking in my previous post with the RUP sample documents (or artifacts), I don't want to perpetuate the myth of RUP being a document-driven heavyweight process. Using templates involves a trade-off: you have a common format for the documents and guides you to the questions you need to ask (who? why?). On the other hand, the template comes in a "one-size-fits-all" format, and you need to adapt the template contents to your project (but to be fair, RUP includes a small project vision template).
The process of discovering what should be in a document is as important (if not more) as the document itself, you’ll find what should be in the document and what shouldn’t be while gaining insight in the problem. Specially true for analysis and/or design artifacts
The goal for every artifact is communication, unless you reached the point when it can be automatically translated into an executable form. And remember:

• You DON'T need to fill every template that a process provides.
• You DON'T need to follow blindly every activity that a process describes.
• You NEED to adapt the process to your project.
• You NEED to follow the process that makes sense for your project in the context of your organization.

(Yes, if you have a process group, you’ll need to convince them…. And yes, that includes not always doing test first, not always pair program, etc…)

RUP sample documents: Inception

Here are sample RUP documents I created for a training I gave:

The requirements set:

BOSBusinessCase.pdf

BOSVision.pdf

BOSGlossary.pdf

BOSUCOrderBizcochos.pdf

BOSUCRetrieveConsolidatedOrder.pdf

The management set:

BOSSoftwareDevelopmentPlan.pdf

BOSRiskList.pdf

The most important ones are the vision document and the use cases. One thing I really like about the vision document is the problem statement, defining clearly the problem to be solved by the system.

One important thing I see missing in many “processes” is an explicit focus on finding what the user needs (can be very different of what the user wants), clearly stating the problem to be solved helps a lot in that direction.

Also you need to have some alternatives identified. How many projects are started without a clear problem to solve? Sometimes they're successful, but you must be VERY lucky to pull this off.

Also the alternatives are important: developing good software is very difficult: sometimes, something like excel is good enough!

Basically, it boils down to clearly defining the problem and have the alternatives in mind instead of jumping blindly into a development project.

BTW, the problem statement is not exclusive of RUP, they're just requirements management good practices. Even is included in the IEEE 830 SRS standard.