Code liability – How to reduce your risk?

It is now widely accepted that source code is not an asset, but rather a liability. This is a very strong idea that has a lot of impact across the IT industry and in the way developers view and perform their day-to-day work.
One of the earliest articles on this subject was published on “Object Mentor”. The article is really good, but while reading it I spotted something I really can’t agree with:
The problem doesn’t go away if you artificially reduce the code. (…) Moving it into metadata and models and other forms doesn’t make it any smaller, and often makes it worse. Hand-crafted code is almost always more readable, smaller, more optimal, more focused, more literary in its style than generated code or funky data tables.
Models will help!


I’m a strong believer in Model Driven Development (MDD). I think models are a great way to abstract low-level code, and can make software much easier to understand and change.  I’m not talking about using models as an intermediate stage to generate a portion of your code. True MDD means the entire development process is done on top of the model. Much like you use C# or Java instead of assembler language, in MDD you use models instead of C# or Java.
This may not completely fix the problem: following the article’s reasoning, at some point the model will become the liability. But it will greatly reduce the risk of this liability for a very large part of your software. Why?  Models mean abstraction, which equals less objects to know and manage thus reducing complexity. Models let you focus on the business problem and not worry about all the plumbing to deliver a scalable, robust application.  Models reduce risk when change is needed and speed up the delivery process.
Hand-crafted code is beautiful… for 5 minutes!
The best guy on the team (you!) builds this really amazing beautiful code. It’s totally optimized, and it’s so wonderfully written that angels weep as they read through the lines of code… And then things change.
The code is handed out to the maintenance team, the requirements change, and assumptions used to build it turn out to be wrong… it really doesn’t matter what the reason is, someone will have to touch your perfect code. And it’s all downhill from there.
Blame complexity
It’s not that other developers who will touch your code are idiots. It’s just that the context surrounding your code is huge, documentation is typically inadequate, and although they think they get it, more often than not they miss something. The system is just too complex.
Once again, MDD provides a huge help in making the system look simpler. It makes it much easier to see the full picture, and it really improves knowledge sharing between developers. Of course there will always be problems so complex that even the model is hard to understand, but fixing the vast majority of situations is a big plus!
Some words of advice
As you probably noticed, I’m a big fan of MDD. But you do need to be careful when picking your tool of choice. A whole article could be written on that subject, but let me just leave you with three tips: Make sure your tool supports the full development lifecycle, prioritize fast change higher than fast build, and make sure the application generated by the model is based on standard technologies, is fast and scalable.
My final advice: quit piling up the debt and start investing in MDD now.
Happy modeling!


About the author

Rodrigo Coutinho

A member of the founder’s team, Rodrigo has a passion for web development, great products, and geeky stuff. He spends his time designing future versions of the OutSystems Platform and dreaming about the cool future of the web.



There is no difference between what you call a model and program code.
If you can do one thing in your graphical tool with UML, I can do the same thing using a pure textual representation. And likely in java, python, ruby or lisp.
The thing is that for now :
– I can write the textual representation faster than you can draw the graphical version
– Code/Text has better support for refactoring
– Code/Text has better support for source control, versioning, branching, merging and support concurrent access.
– IDEs give you better assistance when writing code than UML editor when writing UML diagrams (think autocompletion, quick assist, compile errors…).
– As far as I know, debugging in an UML editor or debugging generated code is not that easy.
– Complexity of generating code from a graphical representation or a textual representation is the same. Ofen the graphical representation is serialized to some XML anyway.
– Virtually any text editor can be used to edit code. It may miss some nice features, but it is compatible. In practice UML tools can’t work nicely together.
In fact some people thing globally. They will like models a lot.
Some people think about details. They will like code a lot.
Problem is… Software is all about details. Generalisation is good… But don’t care of the real complexity of the domain and of real life. In computer science, you can’t avoid dealing with the details.

@Nicolas mentioned that “some people thing globally. They will like models a lot.Some people think about details. They will like code a lot.”
The question is: do we need to split these as two separate worlds?
Can’t modeling and coding live together under the same IDE?
I think it’s wrong to completely separate coding and modeling, and say that they can’t work together and in tandem to increase the quality of apps and the productivity of developers.

Nuno Marques

Things change through times, but CASE tools were the silver bullet in the 90s and they promised what MDD promises today and they failed miserably.
MDD is not even a hot topic now a days and I reckon it’s because of its low applicability. There are contexts where it makes sense but probably not as much as people would wish.
There are various problems, the .Net Framework has evolved quite fast and sometimes breaking backwards compatibility.
Now, imagine that you had to handcraft some code because the tool didn’t have the possibility to do something you needed or, as they show in the examples, you need to fill in some code to have the feature working. If for some reason the model is wrong and you need to regenerate the code from the model, you’ll be in very big trouble.
Either you will have to merge changes and be in merge hell, or code the features again. Unless I’m missing something here, I can’t see any other possibilities.
Maybe you can tell the model to learn from the code you wrote but if you had to write the code in the first place because the model didn’t support the feature, how can this be done?
Also code generated by tools is usually cumbersome and difficult to read, it’s usually not covered by tests and when it is, it only makes sense to generate them at the integration level and above, leaving you with the hard work of writing the unit tests when you have to add code.
What about performance, if you really need to get squeeze every bit of performance possible, how can you evolve the model and keep the performance improvements you’ve done? And this is assuming that the code generated is already highly performant, otherwise you might as well rewrite the whole thing.
But I agree with you that coding and modeling cannot be separated but because they are, in fact, the same activity. as Nicolas pointed out. They just live in different abstraction levels.
The OP does not agree with Object Mentor’s blog post, but I think they’re talking past each other. The OP has different problems in mind than the Object Mentor’s poster had. What this post should have said is in which contexts MDD can be applied and which ones it cannot.
Let me throw a couple of examples, could this tool build github, heroku, facebook, amazon s3 or a social game?

Leave Your Comment