Thoughts on New Technologies in Software Projects

For all customers questions arise sooner or later about technology upgrades and changes in platforms, languages and APIs. When should it be done? To what technologies? How to handle the transformation? The questions can not be answered here, because it is a question which leads to different answers in different organizations, projects and teams.

One criterion to think about is standardization. In a lot of cases it is best to wait until a technology has reached a certain kind of standardization. The technology is supported then for a longer time without to much change and some backward compatibility. Some basic behavior and interfaces are quite fixed and are not to be expected to change to much in a short time. This is especially important for smaller organizations which can not handle too much change in a too short time range due to resource deficits. It can be more safe to wait until some standardization documents are out and some bigger players in the market have fixed some details and have committed their interest. The investment in a new technology is more safe afterwards.

A good example are OpenGL and OpenCL. OpenGL is a long time out now and is one of the standards for 3D graphics programming. It is expected, that OpenGL will evolve over time, but it is not to be expected to be disappearing in a short time range without any notification. To much companies and organizations are involved in the standardization process. One of the next big things might be OpenCL. With companies like Apple, Intel, AMD (, ATI), nVidia,… the list of supporters is long and technologies are evolving.

A wise decision to a new technology leads automatically to a competitive advantage due to the fact that competitors on the market might not have migrated, yet. The own organization’s products are faster, more accurate, more flexible. more easy to use or what so ever. One only has to be aware not to create an incompatible product.

With a change to a new technology one also should think about to put a kind of fall-back mechanism in which might change internally to a former implementation of the functionality to enable customers which might not have the latest technology available to use the own products. For OpenCL as an example, this might lead to a check for OpenCL compatible hardware and if not present to a fall-back to the older implementations. This slows down the application to a former level, but the customer is able to use the product which is more important than having the best performance.

These are just some thoughts on technology migration which came to my mind during some discussions with customers and managers. One should take care about the decision about new technologies. Not to change is not an option and it is also not an option to change the technologies every time there is something new at the market. One has to find the own speed and the right time for one self.

Advertisements

About rickrainerludwig
Rick-Rainer Ludwig is software craftsman and coding enthusiast. He is the founder of PureSol Technologies. PureSol Technologies is a company for software development consulting with a strong focus on clean code and automated tool chains.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: