Just as a consultant can get too wrapped up in the minute details or a disdain of frameworks, product developers can also get hung-up "in the clouds" trying to perfect their UML with design patterns and making sure the various relations between objects are correct, and overall just being too obsessive-compulsive about the design of their application. I've certainly been guilty of this as I hate to start coding something that is not perfect because I'm very detail-oriented. However, as long as you are doing some kind of iterative development, you can always make time in the future to refactor something that doesn't seem to fit correctly. Generally I've found that it's better to take a philosophical approach and try to find the middle ground between perfection and chaos and fix the problems in later iterations as it's much better to get some code done instead of worrying about what pattern to use for a certain problem.

I'm sure you're probably asking yourself something along the lines of, "Well, that sounds great, but what does this have to do with frameworks and the differences between consulting and product development?" right now. To answer your question briefly, both types of developers usually approach problems differently but are ultimately going for the same end result: making sure the product does what it's supposed to and making sure our project stakeholders are impressed. By impressed, I mean floored enough with our results to give us fame, fortune, lots of beer, and a 30'' Apple Cinema monitor. Okay, so none of these things have ever happened for me after a successful product delivery other than a celebratory round of drinks, but I haven't been holding my breath either.

In Summary
Consultants are generally trying to get things done in as few hours as possible, and product developers are trying to make sure that they build a robust code base that they can add additional features to in the future, because they will never find themselves with enough time to implement every request during the first major version of a product.

However, the main point I'm trying to get across is that all developers have varying backgrounds, skill levels, situations, attention to detail, and end goals. As such, perspectives and solutions to various programming problems are always going to be different for each developer. I've been witness to some very bad code over the years (including my own), yet said code accomplished the end goal and the stakeholders in the project were very pleased with the results.

As much of a stickler that I can be at times about standards-based development and using existing frameworks as well as good OO design, I also try my best to keep in mind that there is always someone out there with a better idea or different perspective. Ultimately I'd hope that they'd see where I was going with my process and solution, and that I need to make sure to put myself in the same position if I truly think my way of doing things is much better than someone else's.

The best thing you can do in any situation of contention is participate in a friendly but logical debate using correct terminology (while admitting if you don't fully understand a term) with the end goal of learning something from it without taking it personally. If you find yourself being in the wrong at the conclusion of a good debate, just remember that humility is not a bad thing and we all make mistakes - it's one of the important characteristics that separates a good developer from a great one. Admitting when you're wrong will get you more respect than being stubborn and defensive all because you didn't want to look like someone knew something that you didn't.

In closing, keep up the good work ColdFusion bloggers! I think we've all learned a lot from each other in the past few years. Though our opinions on many topics may differ at times, it's always good to have opposing viewpoints and try to challenge the norm a bit. Whether it's those shoot-from-the-hip cowboy consultants or those dang pattern-and-framework-obsessed product developers, we stand to improve our understanding and skill level by openly acknowledging each others' viewpoints. Maybe we can even work on some of the great community projects together, including the bloated/incredible frameworks like Fusebox, Mach II, and Model-Glue.