• darkblurbg
  • darkblurbg
  • darkblurbg

The Anatomy of Model Driven Engineering

The Anatomy of Model Driven Engineering

Model Driven Engineering (MDE) is all about raising the level of abstraction. It is ironic, then, that many have difficulty defining, communicating about, or working with it, due to it being . . . well . . . too abstract. MDE, as a term, is itself an abstraction. In other words it is a term folks use to encapsulate, package up and hide a whole bunch of details. The difficulty is not so much that it is abstract as it is that MDE is a composite.

“80% of the Code Your Team is Writing is Duplicate Code”

“80% of the Code Your Team is Writing is Duplicate Code”

“80% of the Code Your Team is Writing is Duplicate Code”1   Amount of Duplication “Eighty percent of the code your team is writing is duplicate code.”1 I first ran across this statement in a book called Software Factories1. When I first read that line many years ago, as a developer, I thought to myself, “me? Eighty percent duplicate code? No way! I write deep and profound code all day”, I told myself :). Then the authors of the book go on to further describe that the duplication may not be that obvious, in that the duplicate code and the original new code are interleaved with each other. Go…

Are You Cutting Your Grass With Scissors?

Are You Cutting Your Grass With Scissors?

Perhaps you have heard of the term “domain-specific Language” (DSL) or “domain-specific Tool” in the software technology area. What exactly does this “domain-specific” mean and how does it apply to an organization? Let’s step out of the technical world and discuss a non-software example of this concept and see if it sheds any light or otherwise simplifies what we are talking about. First, we start with having a look at its opposite, “domain-independent”, and begin with our non-software example.