Frederick P. Brooks, Jr. wrote in 1986 the famous article “No Silver Bullet – Essence and Accidents of Software Engineering”. Brooks makes a distinction between essential tasks and the accidental tasks of software engineering. The essential tasks are the fashioning of the complex conceptual structures that compose the abstract software entity. The accidental tasks are the representation of these abstract entities in programming languages and everything else needed to run the software. Brooks claims, and was right, about the following statement: “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.”
In 1995, almost at a decade after his initial article, he wrote the “No Silver Bullet Refired” to answer to all the people that claimed they had created the silver bullet, and to all the people that misinterpreted his words. In the decade 1986-1996 there was no improvement that by itself caused an order-of-magnitude improvement in productivity in software engineering. Brooks saw the following ‘methods’ as potentially delivering improvements of an order-of-magnitude:
- The “Make or buy” question, because if you buy the software it’s immediately available and it’s usually cheaper to buy commercial off the shelf software than creating home grown software.
- The next best thing would be to re-use software components as much as possible. For example with component based software design, modularity and Service Oriented Architecture (SOA). Also using high level concepts fits in this ‘method’ as you are creating a kind of business level language and you ‘re-use’ the language constructs.
- The rapid prototyping and incremental development, i.e. agile, is seen as the answer to the gap between what the customer wants and what IT delivers by creating a fast feedback loop and delivering incrementally, allowing for a change in insights and design.
The conclusion in 1995 was and still is: “Complexity is the business we are in, and complexity is what limits us.”
In this blog I will share my thoughts on Mendix being a silver bullet candidate. Mendix is a platform for the rapid development of business ideas into working applications.
This is not some strange 20 years late attempt to compare Mendix to software from the last century. In this blog I will look at several high level Mendix components and see whether they address the essence or the accidents of software engineering. The importance of looking at the silver bullet paper anno 2015 is exactly the distinction Brooks makes between essence and accidents. Is Mendix making life easier for a designer, a programmer or for the business user? Or for all of them? I will also give my opinion where there is room for improvement in Mendix.
MENDIX CERTAINLY ADDRESSES THE ACCIDENTS
Accidents is probably a term that leads to some confusion. Brooks meant the supporting activities, the coding, the testing and everything else that is needed to get the software to work with the exception of the essence, i.e. the complex design thoughts from analysis to a (mental) model. In the original paper Brooks argues that by 1985 the essence was already more than 10% of the project. So even if you could get rid of the accidental part completely you would not get an order-of-magnitude improvement.
Mendix as a platform supporting the application life cycle in the cloud has certainly addressed the accidents part. With visual modeling in the Modeler the coding speed is very fast. The built-in consistency checking, deploying (to the cloud) and debugging all certainly help a lot.
Now in my experience when applications grow larger the complexity kicks in. Either because the design is not properly extended (the patching disease where a programmer builds around the code he does not want to touch) or the code is getting complex by volume, lacking overview and sacrificing simplicity. So let’s address where Mendix attacks the essence.
MENDIX ADDRESSES THE ESSENCE
The essence is the inherit complexity of software design, the mental modelling of what you are trying to accomplish. A picture is worth a thousand words and the visual modeling simplifies the essence. Mendix is a visual tool, which is able to translate the visual diagrams directly into running code. Mendix really helps both the developer coding the features and the business user specifying the requirements.
Another great benefit of this visual diagrams is that the code becomes self-documenting.
Mendix has Domain Specific Languages (DSL’s) for program flow (Microflows), data (domain model) and forms, extended with query languages you define languages to express the essence in. A DSL, in my opinion, creates a high level language and at the same time keeps the simplicity by being domain specific.
Re-use is aided in the application with entity inheritance, GUI snippets and functional programming with Microflows. An AppStore and import/export facilities allow for re-use across applications.
Besides building re-usable components, several Mendix partners and Mendix developers have built customer-of-the-shelf applications in Mendix. This allows customers to buy a Mendix based application and use the Mendix Modeler to customize it.
Mendix supports agile software development on several levels:
- The integrated tool Sprintr for starters that links stories to model components.
- The speed of development in the platform supports rapid prototyping at lightspeed.
- The feedback-widget from the application closes the loop to automate and speed up capturing and obtaining the user insights.
All together the Mendix platform is really supporting agile, and therefore addressing the desired productivity improvement.
CHANCES TO IMPROVE THE ESSENCE PART
Let me now take the opportunity to provide some advice to come closer to being the silver bullet in the future:
- As an experienced developer in Mendix I still experience some boilerplate coding when setting up new functionality. Mendix created layout templates as a first step. They are kind of a wizard-like way of setting up new forms. I would like to have templates that I can change myself and that stay separated from the places where the template is used, so when I change the template after it is being used, the changes are reflected in the places where the template is used. I would like to be able to define patterns in Mendix Microflows, domain models and layout/ form/ snippets and use those patterns as kind of a function call.
- Make a version for children that is so simple that they get enthusiastic about programming, see for example Scratch Jr., https://scratch.mit.edu/. If children can use the Modeler you win in simplicity and let them express the essence. Partly the children’s version might be a stripped version, so maybe think about making the availability of features in the Modeler configurable and with permissions. In doing so you address the ever growing complexity of the Modeler. Another topic might be a separate DSL for program flow GUI, way beyond the static layout/form/snippets with some actions in Microflows.
- As a developer working agile I am often refactoring code. Make refactoring a topic. This allows for models to be altered even faster with support of the platform in data persistence and saving a lot of work in the tool. Refactoring is a part of live and if you cannot refactor your code this is inhibiting agility and good design in the long run and this is leading to complex software.
- As a developer at a Mendix partner I often work in different versions of the Mendix Modeler, depending on the customer’s version. Often I would like to reuse code that has been created in a later version of Mendix. Make backwards compatibility a topic. This has the additional advantage that more developers can use the latest Mendix modeler and can export from that modeler to older releases.
- As a developer I work for different projects and I would like to share parts of code easily between those projects. The import / export of parts of the Mendix model could be greatly extended by the level of detail (export parts of a Microflow or parts of a domain model) and the bundling of items into export packages, so I don’t have to export 50 Microflows or be forced to put items in a module for exporting purposes.
To conclude this blog I believe Mendix is a great platform. To answer the question whether or not Mendix is a silver bullet candidate, I think they stand out anno 2015 in the manner in which they have addressed both the essence, ‘the inherit complexity of software design’ and the accidental part and cater for a large productivity improvement. And there is still room for a lot more! Needless to say, I believe in the product.
