Bottom-Up Approach = Reverse Engineering = Wrong decisions?
Some people already asked me when I will start with blogging. I really have to tell a lot, but usually cost me quite a lot time to make something clear to myself, and even more to others. But now I’m busy with my Master thesis, this is something I’m doing constantly. This made me to decided to make some time free and share some parts of it. So hopefully this post is just the beginning of a lot more posts that will follow the months from now. I’m known as someone who writes large pieces of text, so I hope they will be interested enough that some people will be read them and respond to them. I start some discussions so I enabled the possibility to respond on posts now.
For my Master thesis I’m doing an investigation on business-DSLs. For a proof-of-concept DSL I had to decide whenever to apply the bottom-up or top-down approach. These two approaches are quite often discussed by people who have to build DSLs. In short, when applying the bottom-up approach, you will identify variation points that will be captured by the DSL by looking at the code. With the top-down approach, these variation points will be identified by looking at the conceptual level. A lot of technically oriented people prefer the bottom-up approach, just to avoid complex or impossible model to code translations when reusing existing code and frameworks for generation purpose.
But how bottom-up is the bottom-up approach? Each structural element within code is the result of a design decision, whenever it is documented or not. I think it is nearly impossible to indentify variation points in a good way without thinking at a conceptual level, even for technology-DSLs. When you have to discover these concepts because they are not documented, the code is not self describing and you are not able to talk with the original designers, I think the process of coming to a DSL has more in common with reverse engineering. Every piece of known and applied conceptual knowledge might been seen as is a form of top-down thinking.
But what is wrong with reverse engineering? This can be best explained by looking at business DSLs. As part of my graduation project I’m building a DSL for an existing system. I made the choice to apply the top-down approach and not having a close look at the existing code before having defined the DSL. By talking to the domain expert I identified a number of customer needs which I would never have detected with the bottom-up approach. This because a lot of the domain experts knowledge and way of thinking couldn’t impossible recognized and restored to it’s original form from the code. This was the result of optimizations made by the functional designer and limitations of the architecture. By using the code as base for the DSL, not only these limitations in translation from concept to code will be introduced into the DSL, but also new during the translation from code to an unknown conceptual level.
During my investigation I even decided make some functionality from the domain experts wish list part of the DSL. An example of this is a multi select option lists on a webpage while the current architecture only supported single select. These additions can often be disabled by constrains on the DSL and enable in the future. I also decided to leave optimizations like reuse of definitions if it made the DSL more complex to understand while the profits were minimal.
My conclusion from my experiences till now is that a pure bottom-up approach will in most cases lead to DSLs that do not cover the target audience, even in the case of technology DSLs. Mistakes in the translation will be made in two ways, from conceptual level to code and back. My advice is to start from conceptual level and involve the target audience in an early stage of design, especially in the case of business-domains. This doesn’t mean you have to avoid compromises when the target architecture doesn’t support some structures, as long as you understand that they will influence the understandability of the DSL by the target audience. In the case of good software designs, the translation of models to exiting architectures and code should be not much more complex in the case of a top-down approach than with a bottom-up approach, especially when techniques like Domain-Driven Design have been applied on the original code. If the translation will seems to be impossible, this might be a sign that the original design doesn’t capture all the needs.
References:
- Steve Cook at al. Domain-Specific Development with Visual Studio DSL Tools. pages 46-48, 457. Addison-Wesley, 2007