I agree with Lonneke that most IT cost is not in development, but in maintaining and supporting an application. I don’t agree that if 100% generation of the last 5% is time absorbing, you should not do it. There is more to JHeadstart than just the time gain in building the pages. I refer back to an old article by Steven Davelaar about 100% generating with Designer/Forms Generator: 100% Generation: No More Excuses! (see http://www.oracle.com/technology/products/headstart/pdf/gen100.pdf ) Some of the aspects described there apply here as well (though I think that JHeadstart provides more gain in the first incarnation than Headstart did for Forms):

The cost vs. benefit of 100% generation is one that must be looked at over its entire payback period, not just in the first incarnation. In the first release of a system, using a rigorous metadata-based approach to engineering systems may require additional design time. However, the payback is in the medium to long-term. The iterative phases of system development, and especially its maintenance and enhancement phases are when payback for generation occurs. [...] One of the most important prerequisites for achieving 100% generation is in the very beginning of the project: a reasonable project planning! If you have relatively inexperienced developers on your project, do not underestimate the learning time.

For this reason I think that we should also try to 100% generate the last 5%, at least if the pages involve reading or writing data collections.

Come on! I think/thought your post was right on the mark Lonneke – no need to apologize, you didn’t call names now did you?
I for one whole heartily agree that JHeadstart lures in the Designer/Forms crowd and gets them acquainted with bad practices from day one. UI generation is bad for anything that is beyond emp|dept, and the 100% generation promise a myth. It was then with ‘Headstart’ and now is with ‘JHeadstart’

I agree with you: JHeadstart will give you more than just generation. But it is not very informative nor fun to read the posts of two bloggers who agree with each other: I decided to focus on the point I disagree with. That concerns the statements that there are only small risks. In my experience, Oracle shops that are experts in Forms and Designer start using JHeadstart. This means they use it *because* it generates code. Because they aren’t expert Java users, and are used to creating PL/SQL procedures and not used to refactoring, they will take everything that is generated at face value. Moreover a lot of people that are used generating Forms from Designer feel you should only generate everything or nothing (this is what I have encountered over the years, not my view of how it should be). Novice or intermediate programmers are intimidated by all the code that is generated at once, they don’t know where to start. Project managers don’t estimate enough time to program because it is generated etc etc. Extending JHeadstart or maintaining the generator is far out of their reach and interest.
Second of all, with ADF BC without JHeadstart you have the same problem: people will take a shortcut and generate business components from the datamodel to build their GUI with. Leading to the problems in the user interface I described. It will reflect the datamodel instead of the conceptual model that it should represent.
To conclude: the problem is that the tool (in this case JHeadstart and/or business components) will lure people into bad habits where it can do real damage. It is something that I have seen with other tools as well: once you get the user interface wrong, you spend a lot of time fixing and rebuilding.
Now, this does not mean you should never use JHeadstart of course: you made a great case for using it that I don’t need to repeat. Also Sandra Muller made a good point: you could easily design the user interface, decide to use ADF faces, create the business components you need and then generate the code you need. You can then save you some days of development in the lifetime of an application. Again, most IT cost is not in development, but in maintaining and supporting an application. It all depends on the business case.
To conclude: No need to change the title: I get your point, I agree with most of it, I just don’t agree with everything Sorry if I hammered away too enthusiastically, I did not mean to hit you…

Thanks for your reaction. Reading your comment here and the article on your blog, I realize that I have failed to get my main point across. I wanted to make it clear that in my mind there is no such thing as a JHeadstart application. We develop ADF applications, with their own specific UI, interaction patterns and functionality. You should not and need not be able to see whether that ADF application was developed by a team of 10 programmers in Canada or a team of 5 whizkids in India working with 3 project leaders in The Netherlands and nor should you have to see whether JHeadstart has been a tool in developing that application. JHeadstart does not define what the application looks like or offers in terms of functionality. The end-user does, and the implementation technology, i.e. ADF, should make it possible.

My whole point was that JHeadstart can be used in certain ways. I very much regard it as an electric screwdriver – or whatever rocking term is used for such an appliance. At first I was hesitant to use one for my DIY jobs. Suppose its battery would run out or the thing would break, then what? But of course when your piece of furniture is done, it does not matter whether you benefited from your power tool or struggled to get those screws in by hand. And if the power tool breaks after half the screws are done, well at least you had the benefit for those first 50% screws.

On my current project, we develop an ADF application. The User Interaction Design was done my someone who does not know ADF. The application we develop, does not look like ‘typical ADF’ in anyway. You would not be able to readily tell the technology used for implementing the application. We also use JHeadstart. In fact, we use more of it than I would have expected, as it turns out that much more of that very un-JHeadstart style UI turns out to be fit for generating after all. However, we can stop generating at any point and continue by hand. Without JHeadstart we would have to do everything by hand anyway, so whatever we got from JHeadstart – as long as it is in the right direction – is beneficial.

For that same reason, I am not afraid of a dependency on the JHeadstart team, as in my view there is none. I get a generator that I can use or not use. If I do not use it, I do everything by hand. If I use it, the first 30-80% of many of my pages is done for me – and then I do it the rest by hand. If the generator is no longer available, I drop it. Nothing lost and potentially a lot gained. As far as the run-time infrastructure is concerned: they consist of a number of well documented sources; my colleague could have written them, but some Oracle team in The Netherlands did it instead. I do not see much danger of a dependency here. We can take these components and start refactoring, extending and complementing them. Again, the gain is obvious, the risks are small.

Furthermore, an important point I was trying to make is that JHeadstart is not only a generator. It is a combination of two things, and even for ADF applications that are completely hand-built, I put it that JHeadstart provides a run-time infrastructure that benefits most ADF applications, regardless of whether they aree generated completely, generated at first than manually finished or not generated at all.

You keep hammering away at the Generation topic. Suggesting that generation will inevitably lead to an application that does not fulfill the user’s requirements in an optimal way. While my whole point was that JHeadstart is not just for generation and is certainly in my view not to be used for complete generation. So in effect, I pretty much agree with all your arguments – only they do not apply to the case I was making.

I was not making a case for generation of all applications when I stated that almost all ADF applications could benefit from JHeadstart. I merely pointed out that for any ADF application you need generic infrastructure, on top of the standard features/functionality of ADF. And JHeadstart provides a set that could well be the first step in that generic infrastructure, saving you many days of development.

Maybe I should have used a different title for my article. Something like: JHeadstart, it is not (just) about generation.

best regards,

Lucas

Thanks for your reaction and best regards,

Lucas