HOME | Blog | YouTube | LinkedIn | About Me         || Calculators    | SoftEng/Tech Posts    | Code/Scripts

Sunday, April 14, 2013

Why is compilation considered evil in software engineering when plugging in new modules? Did we cross the line?

Why is compilation considered evil in software engineering when plugging in new modules? Is it really? Why have we gone so far as the software engineering community?

Since the introduction of XML, the software engineering community has reached the point where for some reason the compilation of your code code has been looked down upon. What do I mean?

I am talking about developing your application to the point where you can change configurations and plug in new modules without requiring anybody to compile your code. This sounds very fancy and it has been the selling factor from the engineering community to the management/decision makers.

The question is: Have we crossed the border and reached the point where the code is very complicated and not maintainable and where the value of this level of configuration is not worth anymore. 

You have to put yourself in the position of a new software developer joining your team or even a long-timer developer who has not worked in that area of the code. How easily can they configure and plug in new modules and how confident they are that they are configuring it properly. If they are struggling with this, then it's not worth it. If your configuration files are becoming so complex that you need to write documentation on how to configure it, then it is not worth it. It is not worth it because your configuration files are becoming so complex that you are writing your complex code that parses these configuration files. Essentially you are building something that is home-grown and we know what the downsides of the home-grown rule engines are.

Please do not misunderstand me. There are software applications that really require home-grown confidential rule engines and this mostly applies to software applications that are very static in its nature and all you are doing is just configuring bits and pieces and plugging in modules to it. However, most software application are NOT static in its nature; they are constantly changing as business requirements are changing. So in that case, you are developing a module that you want to plug in, but you still end up changing the code in your core application anyways. So what did you gain by over-configuring it?

Conclusion:

It is very good to have your software configurable and configurable only to the point where your configuration is self-explanatory and where your code is self-explanatory. Once you reach the point where you need to train software developers how to change the configuration files, then you are crossing the borderline of over-configuring your software for the benefit of not compiling code when you are willing to plug in a module. Compilation is not evil. If your build methodology is very robust, then you will be able to build your code fast, push to production fast and at the same time you are keeping your configuration simple to the point that you don't need to train your developers. 

Keep it simple !


Keywords: #software #engineering #development #compilation #configuration 
<THE END>




No comments:

Post a Comment