1.1. Why MetaFactory?

Once upon a time (in 2004) Marnix Bochove, then working as a senior software developer at a large financial institution, realized that very often he was programming the same kind of code over and over again. So he began to investigate the possibilities of approaching software production just like production in the manufacturing world. Hence the name of the current company: MetaFactory. The aim was to create a software production facility, far more versatile than a common software generator. Most generators can generate rather standard solutions, but often they create ugly code. The idea was that the developer should keep total control over the produced code which should be of eminent quality.

The years went by. Now there is the MetaFactory Composer. A highly versatile production environment which you can integrate into your development processes to an extend that you can choose yourself. It can generate source code in different languages and is independent of any framework.

Every software system bigger than ‘Hello World’ contains pieces of rather generic logic that occur repeatedly in the sources. These pieces are called ‘patterns’. Using the MetaFactory Composer you once create a code instruction for a pattern. Then you can generate all occurrences of the pattern with a push on a button. You might expect that all software developers are yearning for a piece of equipment like this.

But they don’t.

I worked with many engineers, man and women: electrical, mechanical, hydraulical, software, maintenance and documentation engineers. They appear to have one thing in common: a string of Gyro Gearloose’s (in Dutch: Willie Wortel) genes in their DNA. Deep down they want to invent things. And find the perfect solution. But after having found the perfect way, circumstances change (for instance by change requests). And a new quest for the best solution can begin.

The old solutions are buried in the code already created. And remain there until major issues force the engineer to update the deprecated code. And this is what software engineers hate (I know because I’ve been one myself): digging through a multitude of (somebody else’s) source files to get the damned thing working again.

Most software engineers are not eager to leave their cosy environment with their own language, frameworks, programming style and habits. But MetaFactory offers opportunities to improve programming continuously, at a high productivity level and to be more flexible towards change requests and technology changes.

This story is about why Metafactory can be your next step in the professionalization of software engineering.

1.1.1. What do Developers need?

Each year the Standish Group https://www.standishgroup.com publishes the results of a survey on how succesful ICT projects are. According to interviewed ICT managers the most important success factors for a software project are:

• Small projects,

• Strong user commitment.

• Strong commitment of higher management.

• Experienced project manager.

• Clear Business Case.

We know that already for -say- 35 years, but still about 50% of the software projects fail. So there must be other issues that are overlooked.

In their Developers Survey of 2016 (49.521 respondents worldwide) Stack Overflow asked What are your challenges at work?.

Fig. 1.1 Results Developers Survey of 2016 (partly)

It is likely that the efficiency of development processes will deteriorate due to poor documentation, a fragile code base and outdated technologies. And, if the development processes are less efficient than expected, this will lead to unrealistic expectations.

So what developers need is:

Efficient Development Processes, with tooling that:

• Enhances development speed,

• Is flexible towards changing requirements,

• Can easily cope with technology changes,

• Fortifies the Code base and

• Supports documentation.

1.1.2. The conventional way of development

Fig. 1.2 Conventional development

Looking at Fig. 1.2 we see the following:

• Already at the first modification of the blue file, a bug infects the code. This stays existent in all consequent copies.

• At the test all sources must be checked for the bug.

• After a change request all sources (except black, because the change is not relevant there) must be modified.

• Unluckily new bugs are intruduced during modification.

• During the modification from red to black, the developer had a brilliant idea. The implementation of this new insight stays restricted to the black file. The other sources do not benefit from the new insight. As a result the implementations grow apart.

The consequences are:

• Logic (and bugs) end up scattered over a multitude of source files and are frozen there.

• During maintenance there’s a lot of (repeating) work in many files.

• The process is sensitive for differences in style and interpretation and

• Sensitive for changes.

• Progressive insight is buried in individual files.

1.2. Automating the software production

Just like the manufacturing industry:

• Avoid duplication of work.

• Automate repeating or generic ‘patterns’.

• Do the ‘specials’ as you used to do.

1.2.1. Automation, in which case?

There’s a big difference between the needs of an individual user who needs automation for his work processes and the needs of a professional software developer.

Fig. 1.3 User focus on project parameters

The individual user is not interested in code or code quality. He or she is primarily focussed on quick results and the ability to make rapid modifications when questions or requests change. And is not inclined to write many lines of source code. If you want to support this user with automation, a Low Code Solution might be a good option.

The professional developer’s job however is to create source code. And to keep control over it.

Fig. 1.4 Developer focus

In general he or she will be involved in larger projects where the importance of maintainability and code quality grow with increasing lifespan of the project’s endproduct.

If a project’s size is relatively small (little repetition, not too many lines of code) and the demands for code quality and maintainability are moderate, the conventional way of manual programming may suit well. But if the rate of repetition and the demands for high productivity, high code quality and maintainability are higher, the effort to keep control over the quality (bugfixing, consistency, programming style) of a large number of sources increases rapidly. Then conventional programming is not a workable method any more.

Then automation with the MetaFactory Composer is the better way. It eliminates repetition, creates high productivity, supports continuous improvement of the code and keeps the code uniform and structured.

1.3. MetaFactory Code Composer, what is it?

The Code Composer is a source code production environment. It can create:

• Java

• Typescript

• XML

• HTML

The product is source code. Not more, not less. The produced code can be combined with any other code.

So the Composer and its output can blend in with any existing development process. If you like it can take control over the whole process. But if you don’t, you can restrict it to the production of a few files. In any case you’re still the owner of the code and you keep for 100% control over it. You can keep using the frameworks that you are comfortable with.

1.3.1. Developing with the Composer

It’s all about patterns. Patterns are generic, often repeating pieces of code. Take a REST interface, for instance. If you use REST interfaces, you need one for almost every object (entity) in your system. So you end up writing many REST interfaces that are only slightly different. That REST interface we call a ‘pattern’.

Fig. 1.5 Patterns in two projects

In Fig. 1.5 we see two systems, connected to the internet via a WEBserver. Both make use of a database. In the system on top, there live three objects: oranje cap, black car and tree. Each of them needs screen handling functions, a REST interface, business logic, and an interface to the backend. These 4 we call ‘patterns’. Except for the business logic, which will be very specific, the other 3 (screen handling, REST interface and backend coupling) are applicable to all objects (entities) in the system.

And when there is another system with similar objects, as on the bottom of the figure, the same patterns are applicable there too. Patterns are not necessarily confined to a single project or system.

For each pattern you create a Code Instruction. (MetaFactory can supply some standard Code Instructions, but you are not obliged to use them.) The Code Instruction ‘instructs’ the Composer what code to generate for a particular object. So with a single Code Instruction for a REST interface in Fig. 1.5 you can generate 6 (!) REST interfaces.

One code Instruction for an unlimited number of objects?

For the sake of readability we omitted some details. But there are more mechanisms to tune the generation process. The MetaModel and objects can contain meta-data, which control the Code Instruction. And a ‘hook’ for instance enables you to influence a Code Instruction on Project level.

More about this stuff in the next chapters.

1.3.2. The Real Power

The real power is in the interactive character of the process. Whether you update a Code Instruction to honour a change request, to fix a bug, as a result of changing technology or new insights, it does not matter. With a push on a button you can generate all dependent sources again.

At each iteration the quality of all sources will increase. Progressive insight and Best Practices are saved in the Code Instruction. And can be applied in other projects at once.

• Quality improves at each iteration

  • Is saved in Code Instructions and

  • Applied to all generated sources.

• Progressive Insight

  • Is saved in Code Instructions and

  • Applied to all generated sources.

• Best practices

  • Are collected in Code Instructions

  • Earlier produced code profits too

1.3.3. The Big Benefit

In every project you will find patterns. In Fig. 1.6 we see 3 objects (cap, car, tree) and Code Instructions for 3 patterns (screen, database and Rest). Usually the Business logic will be too object-specific to be regarded as a pattern and will be realized by means of a ‘hook’.

Fig. 1.6 4 Code Instructions, 1 MetaModel and a hook. Output: 12 files with source code.

With a Code instruction for every pattern the Composer will generate 12 sources: 4 for each object.

1.3.4. And what’s in it for you, as a developer?

Regarding coding, the focus moves to analysis and working on a next abstraction level. You need to get used to it.

But:

• The really interesting programming tasks will never disappear.

• The need for your specific expertise (Java, TypeScript, frontend, backend, architecture) will only grow.

• Your knowledge and personal development grow along with the Best Practices.

• You will spend more time on analysis and composing, less on coding.

• It becomes easier to adopt new technologies.

• You get more appreciation because you deliver high quality code in a short time and you are flexible in honouring change requests.

• Using the Composer you can deliver the whole project consistent with the latest insights.