With us today is Ravi Kumar, lead developer for Application Factories at CodeGear. Application Factories are tools that generate applications from pre-defined scripts and templates.
DDJ: Ravi, where did the idea of Application Factories come from?
RK: It always fascinates me to step back and take a look at what is going on around us and spend some time reflecting on what the future holds. All of us have thoughts about it, don't we? Well, the idea behind Application Factories came about this way and went like this:
Millions if not billions of lines of code have been written and more are being written every day. Humungous volumes of code are inside companies and power the world we live in, so an ever-increasing volume of code is finding its way to the public square. The code in the public square now encompasses all the way from kernels, device drivers, parsers, compilers, utilities, servers, frameworks on to end-to-end applications.
If you look at productivity today, it is more and more about how one effectively deploys this vast resource inside and outside the firewall and uses it to ones advantage. Reinventing all of this technology is clearly not an option even for the biggest of companies, but as we work with developers and companies world wide (large system integrators for instance) we see this was clearly what they were looking for.
So a typical developer will spend time comprehending their million-line code-base inside the firewall or in the public domain. More often than not that code would have evolved over a number of years and will have very different fingerprints and nuances through its lifetime.
For this comprehension to be practical, a lot of standardization needs to come along and has indeed come along. Yet, a good portion of a developer's day is about searching, debugging, experimenting, isolating resources, knowing the tasks to implement a feature in this code-base, etc. (If you've ever tried contributing something significant to an existing large, multi-year project you will know what I mean.)
Reflecting on all this, a light bulb went off for me -- individual productivity for the most part depends on the developer's knowledge of their often large code-base, and a team's productivity is largely related to the team's collective intelligence of the million-line code base.
And that's where Application Factories came in -- the need for collective intelligence.
There are two vested parties. For a developer or a development team on the consuming side, this is of obvious interest. But also for anyone who is advancing an API, a framework, or a best practice, whether it be open source or commercial, there is a need to look at ways of reducing the barrier to entry.
As we approached building Application Factories, it became a powerful means of code reuse and it opens up many opportunities to take an application-centric view.
DDJ: Okay, so what are "Application Factories" at least in the context of CodeGear tools?
RK: CodeGear has a unique place in the developer tools folk-lore, without a doubt, because they have been at the forefront when it came to compile-edit-debug, windowing libraries, components, RAD, visual design, profiling, UML, Code Archeology, and much more. It's almost unimaginable to work without such a tool set today, and Application Factories is in the rich tradition of CodeGear tools.
We wanted to offer innovation and thought leadership in this space -- addressing bigger issues such as preserving knowledge and avoiding repeated learning. In JBuilder 2007, we migrated over to an Eclipse-base and introduced Software Archeology through UML, code audits and metrics, and performance analysis. Quite often, we all inherit code and need to come to terms with it to be productive, so these are wonderful tools.
At the end of the day CodeGear tools are about developer and team productivity, and one of the biggest challenges we were seeing with developers was application comprehension -- both navigational and knowing how to implement a feature specific to the application.
We implemented Application Factories in Java and in due course will likely follow up on other environments as well.
DDJ: So are Application Factories a methodology or a tool?
RK: Application Factories is a methodology that has been manifested in a collection of features and tools in JBuilder 2008 like the Recipe Editor, Tag Cloud Viewer, Application Diagram, and others.
From the very beginning it was clear the basic Application Factories methodology should be language or platform neutral. The methodology is very simple in its core: If n projects implement your application code, now there will be n + 1 projects. The one additional project will hold meta-data about how to work with the rest of the n projects effectively. Here I use the word project in a conceptual sense.
One part of meta-data provides the ability to capture and share organizational and navigational knowledge about the application. The other part captures what resources need to be created or modified to implement a certain feature -- either as "bread crumbs" or as complete code-generation.
Also, to clarify -- Application Factories is an assistive-methodology. It does not attempt to enforce a new methodology replacing what you are using now. It simply allows you to capture what the developer needs to know to work in that environment with that specific application.
DDJ: To be clear, what problems do Application Factories address?
RK: Three specific things I will point out:
- In a typical development scenario today, application development history walks away. This is a very valuable asset and loosing it is a big productivity loss. Application Factories addresses this by enabling capturing of developer intent and application knowledge.
- Application Factories in JBuilder 2008 ships with pre-built Application Modules. For example, the Ecommerce module is a complete end-to-end Ecommerce application out of the box, plus Application Factories meta-data to navigate the large application with ease and walk through a complete store front setup. The other modules are a data-aware Web application with complete login, reporting and searching capability out of the box.
- Application Factories comes with a full feature set to produce your own modules like the ones shipping with the product. To augment this, http://cc.codegear.com/java/modules hosts a modules marketplace to help create an ecosystem of modules. So, any one interested in adoption of a framework or API, can use this means to build the most typical applications and make them immediately consumable in JBuilder.
DDJ: So where does the concept of "Application-centric IDEs" come into the mix? What are these and what problem do they solve?
RK: Isn't it curious that the IDE presents itself the same way (for the most part) when working with an e-commerce application or a gaming application? The reason is that the IDE is not aware of the application it's working on. In other words, the application doesn't influence the IDE. It's almost always the other way around.
In Application Factories, with the help of meta-data, the IDE offers up "new" tools entirely based on the meta-data -- for instance, a tool to narrow down to reporting related resources, or a tool to change the style sheet for my application.
The basic problem it solves is to enable the IDE to act as a conduit for application specific knowledge transfer and boost team productivity.
DDJ: Is there a web site that readers can find out more about these issues?
RK: Yes, www.codegear.com/jbuilder.