Proposed New Years Resolution: Generate Your Code

Hi Richard,

Thanks for the comment, and glad you're enjoying! Buy vs. build has always been one of those big debates. I theoretically prefer to buy (or even better use open source) instead of building, but I have been burnt so many times with solutions that wouldn't quite do what I wanted (everything from packaged apps to dev environments to frameworks) that I eventually decided to build anything critical to my business, only outsourcing (buy, OSS or third party custom dev) anything that isn't critical to my business.

Not sure exactly how you're comparing app gen to buy vs. build. Would you mind clarifying as whatever way you are asking it, it's an interesting question!

It is a really good question. In my experience the value of an app generator is directly linked to the elegance of the Domain Specific Languages you create. I have found that very different applications can still share similar requirements that can be captured and generated. Broadly there are two approaches. One is functional specific where you look at classes of variability in your e-commerce shopping carts or newsletters and write DSL's to capture those variabilities. This works quite well, but will only take you so far. The other approach which I have been working on simultaneously is to develop DSL's that are higher levels of expression of programming intent. Examples would be the ColdSpring and MG XML files both of which allow you to describe programming intent at a higher, more abstract level than by wiring your components or controllers using a general purpose scripting language directly.

All of this aside, it is still important to create extension mechanisms such as using inheritance of generated base classes with custom subclasses to easily allow for round tripping. I have also engineered some other important extension points into SystemsForge (our in-house generator I'm upgrading).

My short answer is that for anyone creating a fairly large number of custom web applications (lets say more then 3-4 a year) with variability too great to simply implement as a packaged product with property:value attributes, an application generation approach will yield close to order of magnitude savings in the coding, debugging and maintenance phases and potentially similar savings in the quotation and specification phase if they are capable of architecting a software product line and engineering in the majority of the required variability between applications.

The Software Product Line approach will be tough for smaller or less capable shops, but the programming savings using LightBase (when it is released OSS) should be achievable by all. I have read and quoted Fred Brookes "No Silver Bullet" a number of times, but Software Product Lines are no more a silver bullet than being able to generate a Yahoo Stores! shopping cart in minutes - it is simply a different way of creating applications and I really think we're going to see a quantum shift in how the majority of web applications (by volume - not dollar amount) are created over the next 2-3 years. Interesting times.

Depends! With the first (functional) SPL approach, you're right, unless you build a bunch of pangalacicgargleblasters you're outa luck. But here is my question . . . is a PGGB REALLY that different from an email newsletter, portal, job application management system or workflow application? Most have users, roles, security, authentication and maybe auditing/versionsing. All probably have UI templates including lists, views and maybe import/export/approve/delete screens. All of them have objects that need wired together and controllers that need to be implemented. We've developed a pretty decent methodology and set of tools for specifying ANY web app in terms of screens, steps, actions, etc. and then generating the vast majority of the functionality required. Right now we're working on everything from simple e-commerce to a site allowing physical fitness trainers to design exercise programs online and a generation tool for 200 loosely interrelated international sites. There is a level of abstraction higher than ColdFusion but lower that "what kind of shipping rules do you need" and there is a lot of potential for generation at that level as well.

Like most of what I'm doing, no doubt it'll make more sense when I ship code!

Hi Richard,

Agreed. As with all debates, the answers will be obvious as sufficient time goes by. I'm over in the UK right now and I'm already two nightcaps into the evening, so probably a good time to stop!