The CF Blogsphere

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.

That said, there are some things to miss about doing consulting type work for sure:

• 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.

One of the main differences that separate a typical developer serving in a consulting role versus a developer in a product development role is the fact that for the consultant, time is money. Ultimately the end goal is to finish a project within the time-frame and price point that the customer is looking for. On the other hand, a typical product developer is more adherent to process and is more likely to follow the various phases in the software development life cycle, especially as the team and company gets bigger. Time is money for them as well, but in a much different fashion; because they have already been budgeted into a position, the resource that they provide is development time, so they have to work more under time constraints than billing-hour constraints.

When I worked as a consultant and was much less experienced, my process to start and complete a project was something like this:

1. Gather requirements
2. Design the database to support the requirements
3. Code!

As I've learned over time, this is usually a recipe for certain disaster for many reasons that is a whole article in itself. However, this was before I started my computer science degree or had any exposure to traditional software development, and it seemed to be the right thing to do when working under billable hour limits, given my background and experience.

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.