Ah, code generation. I joke with people that I am a computer programmer because I am fundamentally a lazy person - I want the machine to do my work FOR me. Granted, to be more accurate, I want the machine to do EVERYONE's work...
I've written the SQL DDL-to-Objects program a few times. I have it write the T-SQL Stored Procedure for CRUD operations, the VB.NET code for the data access layer, the VB.NET code for the business layer, including a generic list of the object in question with a few handy methods pre-written. Then it's just a simple case of copy/paste into Visual Studio and, presto, custom objects derived from a table design.
But this isn't the first time I've done this.
Going back to 1984 I was working for a company that wrote "municipal software" - tax assessment software, utility billing software, that sort of thing. The Tax Assessment syste was being written from scratch but we had something very rare in the industry - a LONG design phase that assessors helped produce. We had it down to knowing what our indexed files would be (think of them as old-school SQL tables), the relations between them, etc.
We were going to have a LOT of maintenance screens to support all the 'parameter' files. Something like 17 small files that were each needed their own screen.
The system was VAX/VMS based, written in DEC-Cobol, using FMS (Forms Management System) for a front-end screen handler. That was the "official word". I had to write the 17 maintenance programs and I didn't want to. So I wrote the first one and "genericized" my code so that I could clone it easily for the other 16.
FMS had a feature that would produce a Cobol data division from your form definition. It hit me that with all the 1-to-1 screen-to-file field relationships, I could do something neat.
So, if you followed a few naming conventions for the user-editable fields, you had all the information you needed.
I wrote a COBOL "template" that required a single "Search/Replace All" and a "Save As" to properly customize.
Then I wrote a DEC-BASIC program that read the output from FMS and produced a series of INCLUDE files in COBOL. The INCLUDE files covered everything - the FD, data definitions, the COBOL part of the CRUD code, loading the screen from the record buffer and vice-versa, error checking - you name it. I just had to make sure the 'hooks' I put in the program template matched the 'latches' that I put in the INCLUDE files.
You literally went from the design of the screen to a working program in less than two minutes.
When I told my boss that I had a BASIC program writing COBOL code (after all, BASIC was better for manipulating strings) he looked at me like I had 3 heads. The next day when I told him that I had written 10 of the maintenance programs in one day (the schedule said we had 3 days for each program) he didn't believe me until I demoed them all. I was able to knock over a month off the development schedule.
I don't like repetetive work!