Andrew's ramblings

Development life cycles and Coldfusion

Tags: Coldfusion

After having a discussion on backwards compatibility, and future direction in that Application when it comes to bugs.

We all know how easy it is to develop in ColdFusion, we know how much work can be saved from this wonderful language. but the one thing that is never addressed is the Life Cycle of an Application.

Adobe has made it very clear that they will remain 100% backward compatible with older versions, yet they do deprecate tags over time not as much these days but they have done.

One of the major problems I see with Adobes core market, is that they are opening the flood gates to very bad decisions by developers, because to put it simply these developers don't know better. And by trying to remain 100% compatible they begin to adopt bad practices, and this is reflected in a lot of the code that I have seen in ColdFusion.

That is not to say that I am not guilty of that either, but when you make a career in development. One needs to also look at all aspects of the development cycle as well.

Anyone who does take their job seriously, has a plan for migration to newer operating systems, or hardware. On the side of infrastructure, this is very important because if one was deploy a new OS and then later find out after 6 months that the Application will not work with a certain device, or in a certain way because it was not tested.

Having the attitude of no migration path, is just asking for trouble. Let's take an example.

As a developer I have created an Application module, that will enhance the Application and make the work easier for the developers coding the Application. A new version of the language it is written is gets released, and it is all too often that people become complacent that it will work.

That is by far the worst assumption a developer can make.

In the case of ColdFusion there are bugs in it, there are major flaws with it. And that is not to say any other language is not free of these troubles either, the point is that ColdFusion is RAD not as RAD as what it used to be, but it holds its own now because of the feature rich options its provides.

With all these, comes major problems if a developer was to just assume it will work in the next release. And that is the problem, I have seen many comments that show that the attitude of these developers DO NOT consider that a migration path, with full testing is not needed.

That is furthest from the truth, one can never assume that the next version of ColdFusion will not break something.

If you are not looking at Unit Testing your code, and applying coverage to 100% of your code, then I think it is about time a developer looked into it. Coupled with a migration and testing procedure, one can identify if the Application can work on the next release. Unit testing here will pick this up right of the bat, however it should not also be the only way to test an application either.

I have read a book on Maintenance and migration, even though the book is now 10 years old. The principle is still the same, and it goes on to explain how a developer can get into a mode of just band aid fixing a problem. Sure it might fix that problem for now, but it is a temporary solution to fix a problem there and then and is not a guarantee that this will not cause major problems down the track.

So far the attitude of the core market to Adobe's ColdFusion, are the ones who contribute more to the cause of this type of problem. Adobe don't seem to care that much that these people do not follow proper guidelines when deploying applications.

It is high time that this attitude changed, not just from the position of Adobe and their focus when it comes to backward compatibility. But to encourage and promote a migration path, and life cycle of future releases of ColdFusion.

Because until that attitude, and awareness is promoted. Problems with developers coding around bugs will continue, and increases the chance that these applications will break in the future.

Tweet