Newly appointed CFDJ Editorial Board Member Brandon Harper writes: With the proliferation of many respected developers in the ColdFusion community sharing their experiences and knowledge by blogging, we've seen quite a huge jump in both information sharing as well as the discussion of best practices in software development.
These increases in enlightenment also started happening around the time that ColdFusion MX 6.0 was released, which brought a pseudo object-oriented shift to programming in ColdFusion that has greatly influenced the direction of the average CF developer. Who would have thought so many people would be fluent in design patterns and object-oriented terminology four years ago, and that ColdFusion job postings would actually specify this sort of experience?
Given the shift toward blogging as an increasing venue of communication, we've witnessed a fairly powerful community starting to build outside of mailing lists and message forums, previously the places you would most likely encounter those serious about their craft. This was more evident than ever to me when I attended CFUNITED this summer. It was my first big conference (outside of the ones that have been held in Denver), and it was an interesting experience for me. I did my best to introduce myself to people I recognized; while most of them had no idea who I was by name, I mentioned my Web site and the majority of people had a much better idea who I was, especially if they were active bloggers. I thought this was an interesting concept - to be known more for a URL than my actual name, and it demonstrated to me how powerful it is to have your own very small piece of a community.
With an online community comes both good and bad. One of the good things is the availability of so much information, as well as being able to interact directly with so many other people who are intimately involved in ColdFusion. This can also be bad as it's easier to be rude and contriving when posting to a mailing list or a blog rather than saying it to someone in person, so you must think twice about responding tactfully during a heated debate.
Earlier today when I read another great blog post from Joe Rinehart on the recent "Frameworks versus Methodology" debate that has been happening between a few popular ColdFusion blogs, it reminded me of something I've been meaning to write about in my blog, but it seemed more suitable for a long article. A point that he touches on in his entry that I think should be expanded on a bit is the consultant versus product development mindset.
To preface this, I started off the early part of my career working in the consulting world by primarily building Web sites for companies via an ISP, followed by a branding agency for the first three years, and then I made the switch to developing products for companies about four years ago.
One thing I love about product development is that your budget for a given product at its simplest form is dictated by time rather than money. Basically, as a developer, this equates to quite a few things, but the ones off the top of my head are:
- The cool features that are fun to work on (that clients usually won't pay for in a consulting role) do eventually happen.
- Being able to spend time for requirements gathering, modeling, and other general R&D for a new initiative without trying to sell why this must be done to a client.
- In theory, you have the chance to build a mature, scalable, adaptable code base over time and even get a chance to refactor things every now and then rather than hitting a ceiling for billable hours.
- Typically the functionality is more important and more complex to write. In other words, the product has to do something to actually make money, not just have a pretty face to sell things to people.
- Working with a diverse client base on a variety of high profile Web sites.
- In general, you work with more stable, predictable technology. Generally content-based sites, intranets, and e-commerce-based sites are fairly easy to scale rather than an internal enterprise integration type project.
- Getting to start projects from scratch a lot of the time rather than reusing an old crufty code base, which looks more like COBOL than ColdFusion. Or in the case where you are reusing a lot of code, chances are you already have some sort of an established framework that works well and only needs to be customized each time you do a new site.
- Getting to work with cutting-edge, client-side technologies such as Flex.
When I worked as a consultant and was much less experienced, my process to start and complete a project was something like this:
- Gather requirements
- Design the database to support the requirements
- Code!
With more experience and mistakes to learn from, I grew to at least start using my own framework, which was akin to what Fusebox 3 ended up being. It seemed to work well at the time, but I'd always have to bring other developers up to speed about how it worked and make changes to their code if it didn't fit the "standards" of my framework. In general, it was fine if I were the only one working on a given product, but it would get in the way if someone were to work on something with me.
From my experience during the past several years in product development, the paradigm shift to OO development with the advent of ColdFusion Components, as well as completing the majority of my computer science classes, I've learned a great deal about subjects such as object-oriented programming, the software development life cycle, UML, and design patterns. Let's just say that the aforementioned three steps do not reflect the process I use today.
Generally speaking, the two most important reasons for going through the various phases in the SDLC and using proper OO design is to make sure that the resulting product does what it's supposed to, as well as mitigating the risk of the project failing to meet its objectives. Some great side benefits to this is that it gives a developer time to solve most of the business problems upfront, planning out how the objects will communicate with each other, and lays a good foundation for flexibility and expandability in the future. Specifically, it allows developers time to make sure that they design with object reuse in mind - ensuring that objects are highly cohesive, that there is a reasonable amount of coupling, and that the resulting classes fulfill all of the use cases that were specified during requirements gathering.
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.