You are here:

Automation - "Code that writes code"

"Code that writes code" has been my specialty since 1999. For me anyway, it was discovered by accident, yet it became my major focus for a couple years around 2000, 2001, and my most marketable skill from that point forward.

The initial accident happened when I discovered that the code that I was writing would be easier to generate from a script, because scripts don't make the same typos.

I tried it again with surprising success at Nortel in 2000, when I used it to show off and distribute some menial tasks that had no chance of getting done if allowed to be delegated to personell by hand. Once again I was totally surprised how easy it was and made a note to try it again sometime when the stakes were higher.

My first serious persuit was WebAppWriter, which I finished in 2000 and stayed up and running until I finally brought this publicly accessible server down in late 2005. This application wrote complete and functional web applications, including security, logins, and custom create, edit, tabular and delete views for each table that you give it a structure for. This tool wrote apps to fit within the Expresso framework, and was very popular and successful for the initial years. No attempt was made to keep it up with subsequent versions of Expresso, and it gradually fell out of favor.

The applications generated by WebAppWriter prooved extremely durable and easy to customize, and in 2001 and again in 2004 I was able to use this tool to write applications for customers in a matter of days, which I was then able to customize beyond the boilerplate forms and tables provided.

By 2001 I was making presentations to users groups and getting a strong name within the community for my use of code generation and frameworks. It began to be my calling card - I introduced myself as the automation guy.

Also called "Code Generation", this practice is not without it's negatives, see Automation Lessons for a summary of when all this stuff is a very bad idea.

In 200n I used it to generate hundreds of data access beans for a project that was being written all by hand.

Later on that same project, after spending months writing pl-sql scripts for complex data conversion routines, I took a month and automated that same process, so that the same scripts I was writing by hand for days at a time could be written in seconds by merely pointing the generator to the tables in question.

In 2003 I was hired by Lockeed Martin, primarily on the promise of my ability to quickly write code generation scripts for a large implementation of an inventory management application. Things stalled for a couple months, not because of the generator, but because it was difficult to isolate and learn the code that had to be generated. Once that was ascertained, it took about a month to generate then hundreds of thousands of lines of code that had previously been written by hand. This was also a bit of a breakthrough for me because it was the first time that I had used XSL transformations as part of the tool set.

Once the initial code set was written, I worked for several months on refinements of the code to decrease the need for hand customization after generation, finally migrating it to a set of Eclipse tools (see link here).

In 2005, after spending almost a year writing framework and application code by hand, it was time to port the new framework code to the dozens of new tables which had been added into the app. I spent aproximately one month, and once again 10,000 lines of code appeared in seconds.

Again in 2006, after slogging through an endless morass of custom written code in one project for months, I was able to replace about 80% of it in two weeks using a simple sourceforge mda project.

Now of course the whole world is going whacko with this "Rails" thing, so that plus another 20 or so great alternatives already open sourced, there is no need to consider any other type of alternative, once one knows the basics, and has done it a few times.