Code Generators are Not Evil

Recently I had someone ask me “I want to learn to make web sites. Tell, me honestly, if I buy your product, won’t it make me lazy?” I thought that was an interesting question. I combed the web and found several articles about how “real web coders” should not use code generators and that by using a code generator you will never develop the skills of a “real web developer”. I can appreciate some of the comments made in these blogs. But what strikes me as ironic is that these articles are reminiscent, of arguments made 30 years about the “evils” of high level programming languages such as COBOL and BASIC. I remember the arguments that if developers did not understand the assembly code generated, they were not really knowing what they were doing, and that some sort of evil end would come to the software developed by these “ignorant” coders using high level tools. Who could possibly create software when you were completely out of touch about what they were really doing at a binary level.

Well, I openly admit that using high level tools may produce code that is less efficient as hand coding every line, carefully scrutinizing every function and operation. But let’s step back and take a lesson from history of technology. First, things first… there was no “dooms day.” Programs written by “ignorant” programmers using high level programming languages, worked. What’s more, nobody codes in assembler any more, except in very niche applications. What is true is that high level programming languages empowered more people to produce more helpful software that has been successfully adopted by millions of users around the globe. How many programs do we use today were developed using assembler? “Very Few” is the answer.

History shows us that advancement in tools that help deliver the software that people want are not “evil.” Nor is it true that the people using these tools are “ignorant”. I would argue that the people using empowering tools may be “ignorant” about the technical details of what is happening under the covers, BUT they are actually “enlightened” individuals knowing more about the end product. Making technology more usable empowers people with knowledge about the final “solution” to become more involved in producing the solution. Moreover, people using these tools are able to focus more about the “what” the applications should do over the “how” to do it. The end result is better solutions, faster. There is no evil in this. And just because I don’t know how to repair my car, does not mean that I cannot use it to do some very productive things… like getting to work. Software tools are getting more advanced, and like our cars, we can use them to reach our “software destinations” without all being certified mechanics.

I personally grew up on code generators, in the 80’s “case tools” were all the rage. I leaned to design better systems, by worrying less about the “how to build” and more about the “what to build”. I learned that, as a project manager, I could get more productivity from my team, in less time and to higher quality standards by using automated coding tools. I learned that most of the programmers where happier to concentrate on the desired business goals of the project than on the correct syntax for a particular line of code. And to acknowledge the “dooms sayers” that, yes, you cannot escape the technology and that performance still needs to be considered. But that said, it less of an issue than they would like to make it to be. By producing the solution faster, and testing it earlier, you can identify the performance bottlenecks and call in the hard-core techies to “save us all” as needed. But what I found is that, in reality, the performance issues may only be relevant in 15% of an application. The other 85% can operate happily as is. Either there is no performance issue to begin with, or that this particular part of the system is used only by a few users, or that used so infrequently that it is not worth the investment to make it high performance.

Now I’ll share with you the answer I gave to the question “will it make me lazy”. My answer is “No, it will make you productive.” Why would we think it is “lazy” to not do things the hard way? To me, if you are achieving your goals, faster that’s hardly the definition of lazy. For a non-technical user to undertake the task of making a website is hardly lazy. For a professional web developer to not waste time hand coding pages that can be generated out-of-the-box is not lazy. To direct your energy in to value added features rather than debugging code is not lazy. Using the right tools for the job is “smart” not lazy.

If your objective is to learn to code, then a code generator is not going to prevent that from happening. Only you will prevent yourself from learning. Back to my car analogy, just because I can drive my car does not prevent me from learning to be a mechanic. In fact, true story, as a teen I learned all the basics of car mechanics from a small book and my old car. I spent a lot of time learning by doing, starting small, with fixing hoses to eventually rebuilding much of the engine and brake system. Having a car to tinker with did not impede my learning, it helped me learn. Likewise having a code generator to tinker with can actually be a learning aid. By enabling features, studying the code generated you can learn in an interactive, “by example” manner. In the same way that I worked my way “up” in my car mechanic skills; you can work your way up the technical learning curve as you have the need and inclination. But the great part is you can still have your working web site while you are learning.

With the introduction of dbQwikSite Developer Edition, I would say that using dbQwikSite code generator as a learning aid is even more practical than ever before. Developer Edition let’s you insert your own custom code into the generated code. So, you can “tinker” with your pages with ease. You can see how things are working in the code and add your own code to make your pages do more, adding features without having to be an expert. You can learn to code one-line-at-a-time while dbQwikSite fills in all the gaps. And, of course, if you are an expert in JavaScript or Server Side scripting you can make your generated pages do things only you can dream of.

To all the authors of all the blogs I read about “real programmers”, I offer the following counter points.
1) It is not every do-it-yourself web builder’s objective to become a coding guru
2) Understanding code is important but not more important than understanding the web site functionality that you are building.
3) If you bill or are paid by the hour, it would be professionally “negligent” to insist to hand code every single web page when there are tools available to enhance your productivity.
4) Coding is a means to an end, not an end into itself.
5) Don’t sweat it, “real programmers” are still needed, for all the “cool creative” stuff. Let the code generators do all the “boring repetitive” stuff.