I agree. I think the secret to workflow abstraction relies in the relationships between the data. A lot can be inferred about workflow based on the direction, cardinality and type of relationship being represented.

I've seen 8 billion-dollar-in-revenues corps from the inside, they all have the same problems, just different flavors, instances of the same class. I've started to think, maybe wrongly, that the mistake made is stopping ourselves at understanding code, and not businesses. I see a bridge to be gapped, that library is one of the stepping stones.

Back in the day, I used a code generator for a DB system (proprietary language, green screen). And it was the best thing I've ever used. Myself and the SME were able to pound out an entire, pretty sophisticated and exotic, distribution system: Customers, Order Entry, Inventory (this was not your typical inventory, trust me), Debit/Credit memos, shipping, pricing, discounts, crazy tax regimens, and all the ancillary stuff that goes along with it (myriad of reports and supporting tables). We posted to an existing accounting system. We did that in less than a year of work.

You could point it at a table and get a screen and boat load of source code. Nothing amazing here. It handles both flat tables and a simple master/detail relationship. Bread and butter stuff.

Pretty much every other code generator out there is one and done. It's a "wizard", here's a table, and it dumps out a boatload of boilerplate filled in with table specifics. You run it once, then you're on your own.

This did not work that way. It was not "one and done". You used the generator constantly, all the time, over and over and over.

A simple work flow: Create a table, generate a screen. You end up with a screen with CRUD, query (very nice query), and navigation. Go back to the table, and add a field. Run the generator again and you have all of the backing code for the new column, but nothing on the screen. To add the field to the screen was straight forward. Add the field, regenerate, shazam. It's done.

See, the generator worked off of the screen spec, not the table. The original generator would create a default screen, and then generate the rest. The screen spec is the real driver. But, out of the box, it manages all of the fields in the table, it just doesn't show them all. That's why it's up to you to add the field to the screen.

It also means that if you change the table, it WON'T manage the new field until you regenerate. It's static, it's not doing this on the fly. 99% of the time this isn't a crisis.

"So what?" you say? So what indeed.

The next level is where all of the logic goes. The logic is written in to a separate file, with little snippets of code and tags identifying the code. Such as "when field XXX" changes.

This code is then merged with the generated code to make a whole. In the end, you get a blob of derivative source code that combines the generated code dictated by the tables and the screen spec, along with your custom changes. You had complete flexibility. You could outright replace entire sections of generated code with your own code (vs just adding in your changes). The whole lifecycle of the data was exposed to you. You could look at the annotated source code and see where all the tags were that you could tap into.

This was the type of tool that will give you a finished CRUD screen in an hour (with the screen reformatted, the validations, looking up reference fields, etc.), but that you could also use to make complicated programs with boatloads of logic, 1000's of lines of code, long haul core programs that just evolve over the years -- yet you never leave the tool behind.

In all my experience, even "good tools" take you to 80% and then you have to utterly abandon them. There were certainly rare occasions where I just severed a screen completely from the generator and "took over", but the vast majority were never that way. There have always been a lot of "80%" solutions out there. But all "real" projects have the heart of them living in that "20%". The 80% is easy because it's always been easy. The last 20% is hard, and the tools leave you to twist.

But this one didn't.

Mind, it helped that it was green screen. The UX was specifically limited. Modal screens with modal popups. No fussing about colors, fonts, icons, etc., the game was just trying to cram the data on to the 80x25 screen in the first place. So you get a lot of abbreviations and all of the other compromises that made computer systems so popular back in the day.

Now, there may well be a similar tool out there today. I mean, how can there not be. The modern UX environment is vastly complex, but the ones I have seen, I've only seen the 80%. I haven't found anything that works with me on the 20%.

I'd like to think it could be done with the generator creating a base class, and then your code goes in to the a subclass. That might work, but it's not quite the same. It's close. It would be a trick making the base class granular enough. But that would just likely evolve over time.