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.
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.