Frustrating II

Here is a re-post of something I'd had up before, slightly annotated to include more information.

I've had the unfortunate experience of dealing with code generation tools on several different projects, and my abhorrence of them continues to grow.

The problems with code generation tools for a Software Developer - iReport and Websphere Portlet Factory.

1. You click things, you don't write code. I went into software development because I enjoy writing code, not because I find enjoyment in clicking buttons. My heart has been broken every time I've had to deal with one of these tools.

2. Provide you no visibility into the code. You're entirely blind from a code perspective, and have no real way to distinguish if things are not connected up correctly.

3. Provide no debugging or step through ability during runtime.

4. Rare, in my experience, to find one that provides code completion. And if it has, it's been spotty when it did work.

5. There is absolutely no way to test them in any meaningful way via any kind of unit test.

6. If you have to use one, read the book. You have no knowledge of how it's supposed to work without a reference.

7. There is often very little, if any, contextual help within the tool for tasks that you're trying to accomplish. This lends itself to googleing for your answer, and good luck to find someone that's posted anything of value for the scenario you are faced with. Chances are, you won't find it.

8. Oftentimes, the ability to control the same properties of objects or control items are found in different places. Or, labels to set properties across different controls or objects are named the same and appear to control the same thing but in actuality they do not. This makes it very confusing trying to figure out what exactly you are doing.

9. When making a change, a simple textual change, to a control or element... that change doesn't always get applied. And there is no rhyme or reason as to why. Sometimes simply closing the thing you are trying to change and re-oppening that same item will allow your change to take. Sometimes changing the same field but in a different spot (as noted in item #7 above) will work. Sometimes not. It's often hit or miss.

10. Refactoring items is typically a manual process that is error prone and fraught with manual-ness (my new word). It becomes very difficult to change items that have dependencies between them. I've not seen this automated well, if at all.

11. You will waste an inordinate amount of time on things that work one second and don't the next, and then do again even though all you did is regenerate the code a couple of times during your troubleshooting.

12. Sometimes items that get created via the tool will just simply behave erratically, no matter how much you tinker with it to get it to stop doing so. What I mean by this is that I've seen these types of tools implement some type of behavior that I have not told it to do. They just seem to do their own thing. And this newly unwanted behavior screws up what you are trying to accomplish. The unfortunate answer is often scrap the widget/report/whatever you are trying to create and start over. The art is knowing when to scrap it and when to keep banging on it. My hope is that I never use these tools long enough to become that artistic with them. The unfortunate thing is this is one of the most frustrating pieces of these things.