Skip to content

GUI builders, modern development practices, and vendor lock-in

The Paranoid Engineer has declared ‘Screw All Gui Builders‘, with an excellent example of the genre of code that can be produced by one such tool, contrasted against the much nicer hand-written code. Now I can certainly sympathise with his pain. The thing that really gets my goat up, and the subject of this post, is when vendors use a GUI builder to lock the poor developer and the target victim sorry, enterprise, into their entire product suite.

My case-in-point du jour is Oracle’s new Rich Enterprise Applications site and the associated technology. On that site you will find a flash presentation of their technology around delivering and I quote:

multi-channel capable applications that deliver desktop quality, highly interactive user experiences that are pre-integrated to enterprise class server technology.

That sounds pretty good, might be of interest to me. Lets investigate further. Now, a lot this technology is built on top of standards, like JSF, and other commonly used technology like AJAX. The earlier version of the ADF component technology was donated to Apache where it lives as the Apache Myfaces Trinidad project. The new components are built on top of these open sourced components. So far, so much is OK.

But, the kick in the tail can be seen in even just in the quoted sentence above: “pre-integrated to enterprise class server technology” – they certainly don’t mean Tomcat, right? The point of the presentation is induce lock in. However I’m still willing to cut them some slack on this particular point. Of course, if you are thinking about using Oracle’s JSF technology, you probably are already committed to Oracle’s middleware technology anyway – and Weblogic is a perfectly good application server, if you need such advanced capabilities (and whether you actually do is another question for another day).

But what absolutely does my head in, is the insistence the only way to develop for this technology is to write it using their proprietary, non-standard developer technology, aka JDeveloper. This is the point where I have to say, I’m sorry Oracle, but … FAIL. I actually don’t even care if your IDE is even the world’s best! Or even if it comes as an Eclipse plugin. My beef with this sort of IDE integration is the total mind-set that it embodies. The IDE might have all the drag-and-drop interface-building mojo in all the world, but the code it produces will never, ever, stand up to a hand coded model driven off the target domain, using modern agile development techniques that are designed to ensure the most cost-effective, best-quality development delivering timely business process transformation (aka value) that the enterprise prioritises and chooses. Just look at the ADF FAQ on the Oracle Wiki. Half the questions are related to the IDE. Here’s a tutorial style introduction that just assumes JDeveloper as the default way to get access to the Oracle JDF components.

No, no a thousand times NO!

The biggest insult is the way that developers are treated as mere commodities in this whole process. They are just the warm bodies occupying the chair driving the interface. Much like the continually failed dream of developerless development, their primary skill is seen as not “being a programmer” but “being a driver of a software package”. If I said, my financial skills and experience include 10 years Excel and 5 years MYOB – I can haz CFO jobz now? NO?! Why not? It’s insulting, that’s why not.

Software development is a profession, or at the very least a craft, and software developers should be able to choose their own tools. Obviously, some agreement has to be made organisationally, or at least across a single team or a whole project, to use a certain common toolset. Here’s one possible checklist:

We’re writing a Java app, check. Deploying onto Weblogic, check. Database is Oracle 11g, check. We have Scrum as our process framework, check. TDD is in our list of favoured engineering disciplines, check. Maven is our chosen build tool, check. Using Subversion for version control, check. Hudson for a continuous integration server, check. Writing the interface with Oracle ADF, check. Using Crossfire to deliver our web services, check. Spring for application wiring, check. Hibernate for persistence, check.

Each of these things has to be agreed upon at an architectural and organisational level (and obviously I don’t mean to say that each of the above is the only choice for each type of item, I’m just giving examples).

You should note one very deliberate omission from that list, the IDE. Architects might impose a certain application server, a particular approach to application layering, and so on. The developers – at least the senior ones – have to choose and agree, for example, on whether to use Ant or Maven, CVS or SVN, Cruisecontrol or Hudson. But what they do not do, is force developers to favour Eclipse or IntelliJ or Netbeans or JDeveloper. What is the point of taking someone who is super-productive with a particular IDE’s keystrokes and then forcing them to spend six months learning a whole new set, a new environment? That’s not productive! A developer needs to have the IDE get out of the way, become second nature – they need to be thinking about code, not where the menu is for the rename-method refactoring because they are unfamiliar with the keystrokes of the unfamiliar IDE. Keystrokes are muscle memory. You just think, rename this method and your fingers are already on the keys you need to press, without breaking your all-important flow. That’s how a developer is as productive as they can be. A productive development team should have a mix of IDEs (I’d propose that this would be statistically in proportion to the usage patterns of the common IDEs). Then we have the specific example of JDeveloper. I won’t even go into it except to say I’ve never heard a developer do anything but curse it, or maybe laugh at it. But it’s the laughter of the condemned man.

It’s something that vendors really need to get serious about. Rather than presenting me with a seamlessly integrated vision, from developer’s screen, through application server, to user’s screen, their technology presentations ought to think discrete. Each piece of technology ought to live and die on it’s own merits, something I’m sure Oracle’s ADF is perfectly capable of – without JDeveloper. If it’s not capable of being developed productively without JDeveloper, it’s already in the reject pile as far as I am concerned.

This essential information needs to be right up front. Don’t bury the information a thousand web sites deep in your developer portal. Put it right there in the first presentation! Separate the selling of the developer tooling from the selling of the user presentation frameworks and the server technology. Show me how I integrate Oracle ADF into TDD, into continuous integration, into the IDE of the developer’s choice. Because if you don’t, you’ve already lost me as a potential customer. This is the real future of software development. Look at where the major thought leaders of software development are taking development – open source frameworks, inversion of control, TDD, Domain Driven Design, Domain Specific Languages, Agile Methods, delivering real process transformation and business capability as early as possible – not drag and drop with wizards. FFS.


  1. Shay wrote:

    You can use ADF Faces with any IDE you want, at the end of the day it is just a JSF tag library.
    Take the JARs, stick them into your IDE of choice and code away.
    JDeveloper just provides a visual development environment to your JSF application and to the ADF Faces tags – a lot of developers find it useful. Just look at the amount of UI design that is done with tools like Dreamweaver – Visual design makes sense for UI design!

    Want to deploy ADF Faces on Tomcat?
    Here are the instructions:

    Maybe you want to deploy on JBoss?
    Here are more instructions:

    If you are more of a code monkey then a visual oriented developer and you don’t want to see the visual UI? Click the source tab in JDeveloper and code your JSF manually – we’ll give you the code completion, code insight and refactoring you need.
    And the nice thing is that you can switch between the two views and they are always in synch.

    You mention that you don’t know of developers that like JDeveloper – strange.
    When Evans did a survey of developers satisfaction with their tools they found a lot of people liked JDeveloper – it was the top rated Free IDE there.

    (Non-objective JDeveloper/ADF PM)

    Sunday, February 15, 2009 at 07:33 | Permalink
  2. Scot Mcphee wrote:

    Shay, I appreciate that it is possible. What I am really criticising is Oracle’s marketing of the technology. You’re relying on blogs to communicate essential information. It should be right there in your marketing materials.

    The Tomcat instructions seem to assume JDeveloper. But luckily it lists all the relevant jars. But you tell the developer to copy them all to ${CATALINA_HOME}/lib (and you’ve assumed Windows also). Is it really necessary to have all those jars in the server’s classloader context and not in the application’s context at WEB-INF/lib? The JBOSS tutorial is exactly the same.

    Is that list of jar files the full set of transient dependencies? There’s a lot of strange jars there. Or is it tied to the specific tutorial that is being built? It’s not quite a full set of fully portable instructions is it? It should chapter 2 of your user manual.

    Do you provide Maven repositories?

    In the Free-IDE value wars, the problem is you’ve come in third to Eclipse and Netbeans. If you include non-free ones you are fourth behind IntellliJ IDEA. As far as I can tell, that’s the market. I thought Oracle was going to be developing with the Eclipse platform anyway? You are a “strategic member” of the foundation!?

    If Oracle wants to speak to developers like me, and you’ll have inherited a few of us via your purchase of Weblogic, then you better start listening that we want to see the plain-vanilla deployment possibilities supported as part of the materials that “sell” us to the technology. Otherwise we are not sold!

    Sunday, February 15, 2009 at 07:58 | Permalink
  3. Shay wrote:

    I get your point about wanting to see the technical details rather then the marketing – but at least our marketing worked – you noticed our offering :-)

    The next step is to actually try the technology to get a better understanding of how it works.

    I agree that we can do a better job delivering more materials that show the usage of ADF Faces without the rest of the Oracle stack.

    But it will probably always end up being a second priority for us, after we show you how to use the technology on the Oracle platform.

    For the technical points:
    Tomcat – the instructions actually show you how to deploy more than just ADF Faces on Tomcat. The also include deployment of ADF Business Components and the ADF Binding (the other parts of the ADF framework – you can choose to use them or not).
    The reason we put them in the main lib directory is so they’ll become shared libraries and not application specific – for better memory usage I guess.

    Central Maven repository – on our to-do list. Right now some of our customers use their own Maven repositories.

    IDE Value != IDE popularity.
    The survey I pointed to ranked the satisfaction of users from their IDE – and there we beat both myEclipse and Sun’s tools. IntelliJ didn’t make the cut since there weren’t enough users to have a statistically meaningful results.

    Eclipse – we do support developers who choose to use Eclipse – and as strategic members we are doing a lot of work to make sure they can leverage the Oracle platform. We lead the JPA and JSF projects for Eclipse. We created database tooling. We head the EclipsLink JPA offering and more.
    (and we also offer an Oracle Eclipse packaging – OEPE –

    At the end of the day we would love it if developers like you will take the Oracle offering for a test drive – whether you like the marketing or not – the thing we would like to be judged on is the actual technology .

    Sunday, February 15, 2009 at 10:24 | Permalink
  4. Scot Mcphee wrote:

    Hi Shay + thanks for your comments,

    Of course I did notice it but is ‘bad’ notice as good as all that? There’s another thing for developers like myself that your ‘marketing’ (and this includes writing comments on blogs ;-)) has to overcome: and that is a lot of us generally see the whole integrated tooling < -> framework < -> server stack as being inherently a bad thing. I know that CTOs who sign the orders might be fooled by such a pitch, but most of the savvy experienced developers I know will tend to shy away from these types of solutions for what I believe are good reasons (for a start, development tooling is not a decision a CTO – or anyone who doesn’t have to eat the dog food served up – should ever make!). I believe that lot of this tight integration (and even GUI builders in general) gets in the way of modern agile engineering disciplines like TDD and pair-programming and the like, and in my experience it certainly plays true.

    You need to start to show your customers – take it very seriously – that the frameworks can be used with the unix command-line, and typical tools like maven or ant, in modern build environments with agile processes and engineering methods. I mean, before you launch any new development technology, go out of your way to get someone to write a short chapter that looks directly as these factors. Consider Oracle’s BPEL technology – in my opinion a total failure at any of that; it’s a hideous technology, a conceptual dead-end in my view because it just can’t conform into such discipline.

    Also, I don’t want to single out Oracle either; IBM is typically just as bad.

    Sunday, February 15, 2009 at 17:50 | Permalink

One Trackback/Pingback

  1. let x=x › UNIX simplicity and agility on Sunday, February 15, 2009 at 19:14

    […] the course of a series of comments around my post about Oracle’s ADF, I started to think about “vendors” and their technology stacks.  Of all the big […]