AMEN!

Hi Lonneke,

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

I agree with Lucas’ comments, and following his analogy with Do-It-Yourself tools, I would like to add my own.

An electric screw driver makes it easy to put the screws in too far in soft material. For unskilled DIY persons, it is tempting to just pick up the tool and let it do its thing. But that doesn’t mean that the tool is not useful for the job! A good DIY person knows when to slow down or stop the screw driver, so that the screw doesn’t go in too far. And then you don’t have a tired arm.

So don’t blame generation tools for badly trained developers! As the developers of JHeadstart and as consultants that use JHeadstart ourselves in large projects, we always recommend people that start using JHeadstart to attend our ADF JHeadstart Workshop. In that workshop we spend 3 days on ADF without JHeadstart (following a UI first approach) and only 1 day on JHeadstart generation! The last day is spent on using your ADF knowledge to customize JHeadstart (exactly the thing that people that rely too much on the generator cannot do) and on implementing Java EE security. Furthermore, we recommend that during the first period of actually using JHeadstart for an application, you have at least one expert available from time to time to help with those things you would not easily do as a beginner. That includes refactoring out recurring patterns to a single source (separation of concerns), designing your data collections in such a way that they fit the purpose of the UI and are not mapped 1:1 to the database tables but possibly to the format of hierarchical XML data and objects, and more.

It does mean that you will have to reserve time and money for training, learning, getting experienced. But as you say, most IT cost is not in development, but in maintaining and supporting an application, and that is where the biggest payback of JHeadstart occurs. 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.

So instead of urging people to put in screws manually, you should urge them to benefit from productivity enhancing tools by making sure they know how to use them properly!