Reading the always informative blog at http://flexblog.faratasystems.com, I came across a thought provoking paragraph that bears repeating. ( http://flexblog.faratasystems.com/?p=280 )
If you answer the question “How?” first, people tend not to ask “Why?” for quite some time. On the flip side, you will have people doing their parts rather quickly thus producing enormous amount of code to fix when the design problems become evident. The problem with formal coding techniques is the human generated code (thus cut/paste errors) without the ultimate understanding how it will be used and very little testing done while writing the code.
Many quality code generators are available. I have personally used Illudium PU-36 Code Generator, Cairngen and ColdFusion/Flex wizards to generate code used in production applications. I took the time to learn the intent and functionality before using the generated code. My design allowed for generated code but was not driven by generated code. The distinction is important.
If you understand the design decisions inherent in the generated code (and you are technically competent to have written the code from scratch), you are doing a Good Thing using generators. If you view the generated code as a black box that Just Works, expect many sleepless nights and pissed off customers.
Thinking of ‘How’ before ‘Why’ leads to the illusion of easily implemented application designs. Unfortunately, once all the code is generated and wired into the application, any changes to project requirements require non-trivial effort compounded by having to wade through poorly formatted and confusing generated code. Designing an application according to which type of code that can be quickly produced over a design favoring the potential spec changes and anticipated enhancement requests is a false economy at best.
Understanding ‘Why’ helps you build applications that are well designed, encapsulated, hide unnecessary information, guard against duplicated algorithms and allow for future extensibility. Spend time learning the ‘Why’. It will make you a better software designer.