software engineer



Generation Driven Development – Introduction to the idea and to gddify

May 27, 2016
6 min read

gddify on github

leer este articulo en español

Keep your source code blocks updated on every software component on your architecture. Even if they belong to the same file.

Keep your source code blocks updated on every software component on your architecture. Even if they belong to the same file.

Note: GDD and gddify are a work in progress.

Applications are concrete points of view. A point of view that is composed by other points of view. Those from every person that participates in their development. Specially the developers, who create the abstraction from the real information flow using a programming language.

Points of view, or models, are the thing that is observed, plus an additional subjective load from the observer, a meta information. Payload and meta.

Over the last year, many times I have created source code generators. Either using one of the template languages out there (swig, ejs, lodash, etc, etc) or using yeoman. Even with custom scripts.

Also, over the last years, I saw how promises get into the equation on the async world. This javascript objects that promise us some information to be delivered in the future. I always though that this was a very interesting concept, and that it was very clever. Is not only that simplifies the way you can write functions, but also addresses ambiguity in the error handling mechanism. But better of all, it represents the reality better. This is the point which I want to take in order to explain GDD (generation driven development).

As I said earlier, when generating source code, we (developers) are used to use some kind of templating language, or yeoman or some custom script. However, if we take a look at the reality, a template (God bless the templates, I will never criticize them after all that they did for me) is physically impossible, it just does not make any sense to put two things together on the same place and mix them up literally. The “mix”, in the reality, is like a cell-level genesis that grows.

Someone may tell me here that, even if templates are not too close to the reality, they helped us to accomplish many objectives, even unimaginable. And that’s true. Absolutely. But I think that a better picture of the reality here, like promises did, may also simplify the development process.

But let’s take a look at some common problems right now:

– microservices: a lot of overhead on maintenance because the number of projects that compose your architecture

– constant module update: it happens a lot that you use a module out there that may not be updated at the right time for you, you have to fork it and create your own.

– technology decisions: new utilities are released every day, some are the right choice for us and others don’t, and the impact here is important because it may lead to a certain amount of refactor work later on

– unmaintained modules: it’s a common case that some libraries are abandonware because of different reasons

– broken module compatibility: also, there are modules that relies on other modules, and wrappers-only-modules often don’t get updated as fast as the original module, or when they change the version and the interface gets changed too in some way and now we need to adapt all of our projects.

– repeated source code patterns: there are source code patterns that we repeat over and over on our components

– build a generator: is something new and you have to learn how to use it, how to test it, or use some third party generator and learn how it works (like MEAN)

– template issues: IDE’s are not prepared to parse two languages in the same file on most cases

All these are reasons made me think that there is something better out there. There are things to improve.

Going back to points of view. Applications are concrete points of view. So, if we think on how to generate more points of view, we will need to pay special attention to the meta information, which are the perception of the reality, to create and maintain other similar perceptions. We need to observe the observer in order to create it.

From this idea I created this development practice that I called GDD, which stands for Generation Driven Development, which is just to add meta information on the source code that is needed in order to generate it again but with little differences, using the main meta information tool on source code: the comments.

Which is that necessary information?

This can be a long discussion and surely with time and maybe the collaboration of the community I will find things that today I do not see.

Actually, the tool that I created to implement GDD, gddify, supports the thing that my experience told me (my current point of view to create points of view). So let’s take a look at those elements one by one:

  • sw component (swComponent): a software component that contains software blocks. A project. Examples: a webapp, an API, a microservice, or any project.
  • sw block (swBlock): a sw block, a group of files inside a software component with a particular purpose. For example, the files that build the source code into the compiled code (in the js world, maybe gulp related files), or the files involved in a SCUDL (even specs!), or any other group that means something logically or practically to our architecture.
  • source code files: this is the minimum unit for generation. a file.
place holders
Inside place holders, that content will be always the same for that particular file even after updates
  • place holders: This are source code blocks that keep their content the same for that specific file. It is delimited with meta information.

Example using gddify (js)

/* ph constructor */
constructor () {
this.name = 'nico'
/* endph */
  • replacements: objects with information for replacements, which will be used in the synchronization. Their current attributes in gddify are name (which will be used to match the same point from other files), regex (regular expression, which is used to synchronize other files with this one) and value (which is the value for that replacement here in this file).

    Example using gddify (js), please notice that this replacement information is contained inside a special placeholder called replacements and that their attributes are comma separated, and one per line.

/* ph replacements */
/* name, /myClass/g, myClass */
/* endph */


a replacement example

  • stamps: source code blocks shared across components. They keeps always the same content. But, they can be ignored from files.

    Example using gddify (js)

/* stamp toJson */
toJSON () {
return { name: this.name }
/* endstamp */


Stamps are code blocks shared and immutable across components (that can be ignored)

  • ignoring stamps: array of names of stamps that will be ignored on this file.

    Example using gddify (js). Notice that, like replacements, ignored stamps are contained in a special place holder called ignoringStamps.

/* ph ignoringStamps */
/* toJson, parse */
/* endstamp */

Ignoring stamps

Ignoring stamps are those code blocks that we do not want to show this particular file

The description of this software components on the right way, will allow us not just create more components, but also combine blocks, and keep them updated, with no additional effort building generators, and with just one programming language, and with no templates. That is the value that this way of development has, thanks to the change on the model which is at my opinion, better to address these common problems of today.

I consider that GDD has the potential to lower that cost considerably, because it allows you to share code blocks across projects, keeping them up to date easily, and thus brings microservices and other kind of complex architectures that requires modularization to everyone and not only to those who can pay high expenses on development. Improve applications quality and price. That is my personal objetive and the compromise and vision of Integraciones Agiles.


This is a simple introduction to the model of visualizing the problem, soon I will publish more details on the usability, on how to get used to the process, common issues, use cases, more code examples, and much more.


I’m doing this open source without making any money, so in order to keep dedicating time to this kind of projects I need the support of the community. Please do no hesitate to contact me for contributions to the idea, to the source code, donations, services, consultancy or business.


gddify en github

Copyright by nicosommi 🦀