When one goes looking for reasons to use code generators, the articles tend to skew positive. I guess most people need to be convinced that these are good tools. However, there is a dark side to code generators. Well, that may be a bit over-dramatic. However, there are reasons that a code generator should be avoided and definite drawbacks to using one. Allow me to make the case against these productivity tools.

Ignorance By Abstraction

The first problem we can look at is what I call ignorance by abstraction. This effect happens when we shield people from the underlying process for any task. For example, you look at your watch and read the time. You have no idea how it “knows” what time it is. You are ignorant of that functionality or process. Code generators often provide that abstraction. Yes, a developer can always review the source code. However, how often do you see that happening? There may be an initial deep dive into the generated code when the tool is evaluated. That is where it ends in most cases. You assess the tool and then trust it. Future developers may blindly use it and never even see the source code.

Confusing Custom With Standard

Frameworks also suffer from this weakness, but code generators hide it better. This situation occurs when a developer gets so used to how a tool helps, they think it is part of the environment. There are many developer tools that fall into this category. The result can be great for productivity but can also end with tool lock-in or limit career moves. I have come across developers that end up stuck in a job because they are so reliant on the tools that the company provides. That may seem like a win for the company, but it can scare away better talent. These environments also deter those that want to focus on learning a language or environment. Instead, your team is just learning tool usage.

Performance And Maintenance Woes

An often overlooked weakness in code generators (and frameworks) is how they provide a general solution. In some cases, this just leads to unused code. On the other hand, it can lead to slow code that is difficult to maintain. It can be frustrating and time-consuming to sort through excess code while debugging. There also are performance issues that often arise. The best way to build a code generator that allows for extensible code is through abstraction. However, those abstraction layers take time to process during runtime. That can cause performance issues that cannot be overcome. The generated code provides a baseline that cannot be moved without removing the tool. When you hit those sorts of walls, you will hear a lot of wailing and gnashing of teeth.

Regeneration Nightmares

I worked on code generators early in my career for a tool called Power Builder. We ended up often having more layers on top of the primary tool than it supported. We ended up spending hours each week in generation and regeneration and compiling cycles. I lost track of how many hours were spent in non-productive waiting for a system process to complete. This was not uncommon in those days of application compiles that often took dozens of minutes or more. Nevertheless, we had to be aware of what might be over-written in our code during a regeneration process. Likewise, there are side effects we might have on the same. I am not sure the resulting time savings were worth it.

Scalability and Extension

That leads to another weakness code generators can run into. They do not always scale. I have run into this often with RDBMS object mapping generators. The tools have an approach that makes assumptions that make sense until you get to large or complex solutions. The problems may occur as name collisions, objects with too many properties, tables with too many columns, or overhead that buries the system. Consider what audit information adds when you scale it to large and complex systems. Do you really need audit information for every data lookup item?

While some solutions and generators provide configuration or customization, that can also be expensive in both time and performance. There is a chance that an update of the tool or even a new code generation will break custom code. Those changes may also fall outside of the patterns the code generator uses and have a negative impact on application performance. Think of it as the tool plotting a specific course through the generated code. Then, the customization tries to change the course. There is a form of working against yourself that occurs in those situations that can cause maintenance and performance degradation.