According to my last post, I can draw a piston in a CAD program and have a (CAM) milling machine automatically produce the output.  Big deal, old hat, so what?  In the software world, we are dealing with sizes and complexity way beyond a piston.  There is no doubt of that.  However, in the design of a race car engine, it is not just the pistons being designed (and drawn), but also the aluminum engine block, rods, bearings, crankshaft, etc.  In fact, everything is designed and machined. And in the case of a race car engine, all of the parts are hand assembled in the end.

 

Thats because, people will say, that an engine is a well known entity and we have done them over and over again for what, 75 years?  I put it to you that a software invoicing application, is an invoicing application, is an invoicing application.  Just like the hundreds of thousands (millions?) of login dialog boxes that we, as programmers, continue to proliferate on an ad hoc, one off basis, we continue to maintain that every software job is 100% custom.  I call bullshit.  Btw, so does the CEO of SAP See slide 12.

At 5by5Software, we performed 25 application integration projects over a 4 year period, all of them very different for different vertical industries, yet they were all the same.  We knew the names of the applications (i.e. end points) to be connected, the names of the adapters, connectors or interfaces (whatever you want to call them) to each of these applications and whether we could purchase adapters off the shelf or we would have to build them (which was the only custom development piece in the entire project), the data (i.e. XML schemas) or messages that flowed to and from the application integrations, what type of communication it was (i.e. one-way asynch, one-way asynch with response, two-way request response, two-way synch on aysnch) and which application triggered the business event to kick-off the integration and whether it was a scheduled event or not.  Thats it.

 

In fact, that is it.  Sure I am leaving out some details, but those are just implementation choices and do not affect the fundamental design pattern as stated above.  In fact, every application integration job will have that same pattern, over and over again.  What does this have to do with code generation?  Well, everything, actually.  If the pattern is repeatable, then there must be a way to define all of the pieces or parts, just like in our race car engine up front.  If we can define (and draw) those parts (pieces, components, whatever) 100% complete up front, then we can code generate the solution, cause this is the same thing over and over again.  Some would call these software product lines (not what your think in the traditional sense of the term "product").

 

As discussed in the previous post, we seem to have software design patterns for everything, so why are we not using code generators with these patterns?  Do our tools suck?  Are we daft? Are we resistant to change?  Fearful that code generation is a career limiting move?  What then?

 

Next post, more code generation - software factories