Discussions

General J2EE: Code Generators - Death to Programmers

  1. Code Generators - Death to Programmers (7 messages)

    Recently I’ve been getting into some heated debates about code generation and the place it has in our ever so changing world. And most of the discussions have grounded down to a concern on many peoples mind; that these tools will effectively put an end to many positions normally filled by a software engineer.

    Now it’s a known fact that code generation tools have been around for a long time now. And after of doing a little web research I wasn’t surprised that most of the major players out there have taken a stab at this in various flavors. But it appears that recently this has been gaining a lot of stream. Take for example the latest XML Journal I received recently. In it Ajit Sagar (spelling?), the editor-in-chief, completed his monthly article in which he briefly mentions code generation and automation. Though his statements in generally appear as overly dogmatic, his mentioning does bring up it’s growing use. That combined with plethora of tools that are coming out (some I’m even using), various articles I’ve passed and conversations I’ve had started to make me think; where does all this stuff belong. As far as I can see there are several types of generators out there:

    - The kind that a shop would put together to perform a rather complicated or tedious task together to make everyone’s life easier, i.e. something to generate EJBs that conform to a process and workflow that has been adopted by that shop. These I see as purely beneficial, and yes some might complain that your loose some fine control but that is easily overcome if it’s something done in house.
    - The Type that is common in today’s case tools, generating code from UML and design patterns
    - And the third, which makes business managers, salivate and some engineers roll their eyes. The kind that put the power of direct changes in the hands of the managers. And I’m not talking about CMS even though I would like to lump eprise/divine in with this group

    It’s the third that really gives me the goose bumps. I’ve had the pleasure of working with various incarnations of this recently. Namely, products put out by ATG and WebMethods. Without going into the details of these they have the premise of allowing the business manager to directly modify business processes through their UI tool. They talk about things like Scenarios, Process Flows, Drag and Drop interfaces common to today’s WYSIWYG tools, business rules, and so on. And I have to admit it at first these seem like really good things. But then I began to work with these tools, and it didn’t take long to realize specialized these tools have become. They’re so proprietary in terms of their architecture that I was cursing the days I ever laid finger to keyboard. They even have their own nomenclature to describe basic and universally excepted terms and practices.

    In attempting to be the absolute solution they’ve effectively created a black box that is totally inaccessible. Their solution was built by taken a snapshot of the industry, with it’s ever changing requirements and direction. And I can only shudder at the thought of the vendor lock-in these solutions are providing.

    As far as where is the post go, I’m wondering how the collective users here feel about code generators in general. I know that after my conversation with a lad who says he’s been working on a tool for the past three years to provide the ultimate code generation tool I cringe with that thought that in the near future I might have to deal with another black box implementation promising the world.

    Threaded Messages (7)

  2. Code Generators - WITH APOSTROPHE[ Go to top ]

    Recently I've been getting into some heated debates about code generation and the place it has in our ever so changing world. And most of the discussions have grounded down to a concern on many peoples mind; that these tools will effectively put an end to many positions normally filled by a software engineer.

    Now it's a known fact that code generation tools have been around for a long time now. And after of doing a little web research I wasn't surprised that most of the major players out there have taken a stab at this in various flavors. But it appears that recently this has been gaining a lot of stream. Take for example the latest XML Journal I received recently. In it Ajit Sagar (spelling?), the editor-in-chief, completed his monthly article in which he briefly mentions code generation and automation. Though his statements in generally appear as overly dogmatic, his mentioning does bring up it's growing use. That combined with plethora of tools that are coming out (some I'm even using), various articles I've passed and conversations I've had started to make me think; where does all this stuff belong. As far as I can see there are several types of generators out there:

    - The kind that a shop would put together to perform a rather complicated or tedious task together to make everyone's life easier, i.e. something to generate EJBs that conform to a process and workflow that has been adopted by that shop. These I see as purely beneficial, and yes some might complain that your loose some fine control but that is easily overcome if it's something done in house.
    - The Type that is common in today's case tools, generating code from UML and design patterns
    - And the third, which makes business managers, salivate and some engineers roll their eyes. The kind that put the power of direct changes in the hands of the managers. And I’m not talking about CMS even though I would like to lump eprise/divine in with this group

    It's the third that really gives me the goose bumps. I've had the pleasure of working with various incarnations of this recently. Namely, products put out by ATG and WebMethods. Without going into the details of these they have the premise of allowing the business manager to directly modify business processes through their UI tool. They talk about things like Scenarios, Process Flows, Drag and Drop interfaces common to today's WYSIWYG tools, business rules, and so on. And I have to admit it at first these seem like really good things. But then I began to work with these tools, and it didn't take long to realize specialized these tools have become. They're so proprietary in terms of their architecture that I was cursing the days I ever laid finger to keyboard. They even have their own nomenclature to describe basic and universally excepted terms and practices.

    In attempting to be the absolute solution they've effectively created a black box that is totally inaccessible. Their solution was built by taken a snapshot of the industry, with it's ever changing requirements and direction. And I can only shudder at the thought of the vendor lock-in these solutions are providing.

    As far as where is the post go, I'm wondering how the collective users here feel about code generators in general. I know that after my conversation with a lad who says he has been working on a tool for the past three years to provide the ultimate code generation tool I cringe with that thought that in the near future I might have to deal with another black box implementation promising the world.
  3. Code Generators - WITH APOSTROPHE[ Go to top ]

    Code generators will not replace programmers until code generators work using a CPU(s) that is modeled after, and works like, the human brain. A CPU like that will cost a lot more than a real human for a long time. Artificial Intelligence does not exist. Code generators are extremely primitive and can create just as much bad code as good/usable code. The idea is just plain silly, and will remain so, at least in most of my lifetime.
  4. Code Generators - WITH APOSTROPHE[ Go to top ]


    I use code generators as much as possible, and I build code generators as much as possible.

    Do you want to code a Swing or html gui by hand, or do you want to use a visual composition tool?

    There is no need to be afraid of code generators. They will not take your place, someone has to build the code generator.

    There will always be a need for intelligence and experience, and custom built code, but let's face it, as this discipline slowly matures, more and more of the coding tasks are boring and repetitive.

    For example, a typical project built here consists of:

    Applet talking to
    Servlet talking to
    Session Bean manipulating
    Entity Beans.

    The Applet is generated by VAJ.
    The Servlet is generated by a custom tool.
    The Session Beans are generated by WSBC from a UML model or by VAJ wizards.
    The Entity Beans are generated by WSBC from a UML model or by VAJ wizards.
    The CMP persistence is generated by VAJ using VAJ wizards.

    The data structure classes passed around are generated from a UML model, including the code to turn them into and back from XML.

    Everything can be customized if needed.

    They only thing not generated here are the business rules (but it could be).

    Why would I ever want to write all this other code by hand and get it wrong?


    For an extreme view on this point, check out the "Model Driven Architecture" papers over at the OMG site (www.omg.org).

  5. Code Generators - WITH APOSTROPHE[ Go to top ]

    Yes, I agree that the code generators are primitive and worse is proprietary in most cases.

    The problem however is that the marketing dept in these vendor companies do not portray it as such - it is always the "silver bullet" for the business managers. And the managers buy into this idea of "a click here & a click there & voila I've defined new business process". As the first mail pointed out, in today's world of rapidly changing requirements & new methods of streamlining the business, these "stuck in time" code generators are a major pain - especially to the programmers who support these tools in-house.

    The major deviation between what the tool promises and what is delivered is lost on the business managers - who make the ultimate buy/reject decision.

    Would love to hear more views on this.
    --Das
  6. <rambling>

    I think that code generation has its good points and also its bad points. The way I look at it is that if you want
    to understand HOW and WHY the program works, you will do the stuff by hand. Yes, I get tired of coding the same ol thing over and over again, that's why I create a repository of commonly seen code and when I need it, I pull it in and begin customizing it.

    For prototyping and getting a quick demo up and running,
    code generators can be a lifesaver, especially when your
    boss comes running up to you 1 day before a client wants some sort of protoype. I also use a code generator to generate some basic CMP beans, but I always go back and make sure that the generated code meets our company's readabbility and other coding standards...


    </end-of-rambling>
  7. We were using JBuilder Enterprise 6.0 for stuff. Admittedly I hate write descriptor files for EJB's.

    However, we found two things.

    First: The people who were generating code ended up with code bloat, and code that was algorithmically not so good. It was trying to cover *everything* and generating way too much stuff to do it.

    Second: The other people liked JBuilder, but they weren't even doing any code generation. They just liked the debugging, code completion, cvs browser etc. Admittedly, they definitely have the coolest CVS integration I've seen(their little history/diff/browser thing rocks). But, they weren't using even a good portion of JBuilder's $3,000 worth of features.

    I was defintely in the latter category. Switched to Intellij, and that's much better (still miss that cvs thing though).

    We still have some people using JBuilder E6, but we'll prbably stop buying new versions. Intellij is just too cool, and too cheap comparatively. If we did go with JBuilder, it would be one of the cheaper, non-enterprise versions. The code generators were just no good for us.

    Lastly, I do agree with Cedric, it can be really great for prototyping. Speed things up a bit.

    -Newt
  8. Code generators could actually be a good thing if there's a sound underlying abstraction/component/application model for which the code is generated. The problem is that most vendors hide a proprietary (and frequently, not a generalized well-thought out) model underneath. In this case, developers encounter the "cliff" syndrome... the drop-off happens when development hits the flexibility limitations of the 4GL tool, only to realize that tweaking the generated code is unweildy.

    This is likely to be especially true with business process management tools. Hitting the flexibility ceiling happens quite quickly and then you realize that the tool generated 10,000 lines of declarative (e.g. XML) code. Now you're really on your own but this should come at no surprise. There is no well-thought-out abstraction underneath.

    In many cases, a good abstraction with no code-generating tool on top is preferred to a nifty code generator with no appropriate underlying abstraction. Does JSP ring a bell?

    $.02,

    -Doron