Craig Bolon
Top achievements
Rank 1
Rank 1
Craig Bolon
asked on 25 May 2007, 04:11 PM
May 25, 2007
Dear Telerik forum --
We have been using RadDatePicker v. 1.6 for about a year, and before introducing some changes to associated software features we decided to try the most recent v. 2.1.
Total disaster. Both client-side and server-side interfaces broke, and our carefully tuned calendar appearance turned to a Picasso. We have gone back to v. 1.6, where we will stay unless the unlikely happens and we can somehow afford another 1-2 days of experimental programming.
Users need for Telerik to adopt a strong policy of release compatibility. Bad design decisions are regrettable, but changes that break code are unacceptable. A continuation of current policy will zero out the worth of maintaining support.
-- Craig Bolon
Brookline, MA, USA
Dear Telerik forum --
We have been using RadDatePicker v. 1.6 for about a year, and before introducing some changes to associated software features we decided to try the most recent v. 2.1.
Total disaster. Both client-side and server-side interfaces broke, and our carefully tuned calendar appearance turned to a Picasso. We have gone back to v. 1.6, where we will stay unless the unlikely happens and we can somehow afford another 1-2 days of experimental programming.
Users need for Telerik to adopt a strong policy of release compatibility. Bad design decisions are regrettable, but changes that break code are unacceptable. A continuation of current policy will zero out the worth of maintaining support.
-- Craig Bolon
Brookline, MA, USA
5 Answers, 1 is accepted
0
Hi Craig,
We are very sorry to hear for the upgrade problems you have experienced.
Backwards compatibility has always been a top priority at Telerik and we always strive for easy upgrade process for all products. As all developers know, software vendor are sometimes faced with the tough choice whether to introduce breaking changes for old features/APIs and thus provide new and better capabilities which were impossible to implement with previous architecture and design. We have always been on the edge of new technologies and sometimes introducing new features comes at the price of changing APIs. It is a general policy at Telerik to only introduce breaking changes when the benefits of the new version significantly outweigh the disadvantages of not having a straightforward upgrade process. Nevertheless, in the rare cases when breaking changes are introduced we do our best to thoroughly document all changes and encourage customers to go through the "Changes and backwards compatibility" articles before upgrading to a new major version.
Please, carefully review this documentation article and let us know if you still experience any problems -- we will be happy to help you along the upgrade process:
http://www.telerik.com/help/aspnet/calendar/?cal_ChangesAndBackward.html
Regards,
Ivo
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
We are very sorry to hear for the upgrade problems you have experienced.
Backwards compatibility has always been a top priority at Telerik and we always strive for easy upgrade process for all products. As all developers know, software vendor are sometimes faced with the tough choice whether to introduce breaking changes for old features/APIs and thus provide new and better capabilities which were impossible to implement with previous architecture and design. We have always been on the edge of new technologies and sometimes introducing new features comes at the price of changing APIs. It is a general policy at Telerik to only introduce breaking changes when the benefits of the new version significantly outweigh the disadvantages of not having a straightforward upgrade process. Nevertheless, in the rare cases when breaking changes are introduced we do our best to thoroughly document all changes and encourage customers to go through the "Changes and backwards compatibility" articles before upgrading to a new major version.
Please, carefully review this documentation article and let us know if you still experience any problems -- we will be happy to help you along the upgrade process:
http://www.telerik.com/help/aspnet/calendar/?cal_ChangesAndBackward.html
Regards,
Ivo
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Craig Bolon
Top achievements
Rank 1
Rank 1
answered on 02 Jun 2007, 11:53 AM
June 2, 2007
Dear Ivo --
Thanks for your response. We had already seen the KB article about changes to RadDatePicker. That does not help us. We simply cannot afford the time to adapt and revalidate our application software. It is a business expense for which we would receive no return.
Most software companies, including ours, earn a significant part of their revenue from support fees. Telerik fees are on the high side but would be justified, given the responsive and generally helpful service. However
Telerik is putting its support revenue at risk.
For most customers, including us, costs of reacting to changes in Telerik controls that break our code are far higher than fees for Telerik support. We cannot afford them, and therefore we will probably never upgrade the controls. Since we do not upgrade them, we will probably no longer need Telerik support.
If Telerik wants to keep customer loyalty, reflected in support fees, then it must forbid changes that would break our code. Any exception should be extremely rare, perhaps once in four or five years, and with ample and prominently advertised advance notice.
-- Craig Bolon
Brookline, MA, "USA
Dear Ivo --
Thanks for your response. We had already seen the KB article about changes to RadDatePicker. That does not help us. We simply cannot afford the time to adapt and revalidate our application software. It is a business expense for which we would receive no return.
Most software companies, including ours, earn a significant part of their revenue from support fees. Telerik fees are on the high side but would be justified, given the responsive and generally helpful service. However
Telerik is putting its support revenue at risk.
For most customers, including us, costs of reacting to changes in Telerik controls that break our code are far higher than fees for Telerik support. We cannot afford them, and therefore we will probably never upgrade the controls. Since we do not upgrade them, we will probably no longer need Telerik support.
If Telerik wants to keep customer loyalty, reflected in support fees, then it must forbid changes that would break our code. Any exception should be extremely rare, perhaps once in four or five years, and with ample and prominently advertised advance notice.
-- Craig Bolon
Brookline, MA, "USA
0
Hi Craig,
Thank you for the follow up and the additional details. We completely understand you position and let me assure you that we carefully consider all viewpoints before deciding to introduce breaking changes.
Every day we receive customer requests for new features, additions and improvements. We carefully review all these and are usually very quick to implement new things when they can fit in the existing framework and architecture. Of course there are cases when new functionality can not easily coexist with current design and if we want to improve on the controls we need to change APIs. This happens very seldom and only at new major versions. We thoroughly document the changes and encourage customers to read them carefully before deciding whether to upgrade. There are many customers who are ready to change their code in order to benefit from the improvements we have introduced, however there are some like you who can not afford to upgrade and prefer to stay with the previous version.
When we strive to improve our products with every new technology or design we inevitably face the tough choice of introducing breaking changes. We will be very happy to hear everyone's experience and suggestions how we can improve on our release policies.
All the best,
Ivo
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Thank you for the follow up and the additional details. We completely understand you position and let me assure you that we carefully consider all viewpoints before deciding to introduce breaking changes.
Every day we receive customer requests for new features, additions and improvements. We carefully review all these and are usually very quick to implement new things when they can fit in the existing framework and architecture. Of course there are cases when new functionality can not easily coexist with current design and if we want to improve on the controls we need to change APIs. This happens very seldom and only at new major versions. We thoroughly document the changes and encourage customers to read them carefully before deciding whether to upgrade. There are many customers who are ready to change their code in order to benefit from the improvements we have introduced, however there are some like you who can not afford to upgrade and prefer to stay with the previous version.
When we strive to improve our products with every new technology or design we inevitably face the tough choice of introducing breaking changes. We will be very happy to hear everyone's experience and suggestions how we can improve on our release policies.
All the best,
Ivo
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Craig Bolon
Top achievements
Rank 1
Rank 1
answered on 09 Jun 2007, 12:46 PM
June 9, 2007
Dear Ivo --
Your description of design policies sounds sincere, but observations of what happened in recent revisions to RadDatePicker do not bear them out. We fear similar problems are soon to emerge with RadGrid, which we use more intensively than RadDatePicker.
We did not see any RadDatePicker changes which break code that were truly necessary. In each case we looked at, we saw that careful design could have provided new function without disrupting existing function. So we feel Telerik has not been fully diligent with priorities.
As software product developers we face the same issues that Telerik does with each release. Our customers would not accept disruption costs on the scale and frequency of those Telerik generates.
-- Craig Bolon
Brookline, MA, USA
Dear Ivo --
Your description of design policies sounds sincere, but observations of what happened in recent revisions to RadDatePicker do not bear them out. We fear similar problems are soon to emerge with RadGrid, which we use more intensively than RadDatePicker.
We did not see any RadDatePicker changes which break code that were truly necessary. In each case we looked at, we saw that careful design could have provided new function without disrupting existing function. So we feel Telerik has not been fully diligent with priorities.
As software product developers we face the same issues that Telerik does with each release. Our customers would not accept disruption costs on the scale and frequency of those Telerik generates.
-- Craig Bolon
Brookline, MA, USA
0
Hello Craig,
I see your frustration and I am really sorry that our latest changes are the major cause. I will try to provide some further details hoping to illustrate our point of view and help you with the migration odyssey.
A lot of customers were unhappy with our initial calendar design and we had to do something about that. The most important things that we had to fix were the awkward VisualSetting objects and the broken support for empty values. The visual settings were a bad case of the NIH syndrome that were very hard for people to use. People could not configure their control without getting help from our support officers and that was very unproductive both for us and for customers. That is why we did the conscious decision of breaking backwards compatibility and moving to native ASP.NET Style objects to implement control styling. We realized that this may be hard for existing customers, but we believed we did the right thing as the control is much more usable now.
The empty values support was another pain in the neck. The RadDateInput control had a design flaw that used the MinDate as an empty value. Again this unintuitive behavior caused so many bugs and so much grief to new users, that it had to go. The RadDateInput control in RadInput 2.0 has proper support for empty values and its SelectedDate property is now of a nullable DateTime type. This had to be changed for RadDatePicker too: had we left it as is we would have done much to help customers as most of them used RadDateInput as a part of their datepickers.
Again, I apologize for the pain we have caused to both you and other existing customers. I hope it was all for the better. I would like to offer our help in your migration process: we can even post the lessons learned here so that they help other customers facing a similar problem.
Kind regards,
Hristo Deshev
the Telerik dev team
Instantly find answers to your questions at the new Telerik Support Center
I see your frustration and I am really sorry that our latest changes are the major cause. I will try to provide some further details hoping to illustrate our point of view and help you with the migration odyssey.
A lot of customers were unhappy with our initial calendar design and we had to do something about that. The most important things that we had to fix were the awkward VisualSetting objects and the broken support for empty values. The visual settings were a bad case of the NIH syndrome that were very hard for people to use. People could not configure their control without getting help from our support officers and that was very unproductive both for us and for customers. That is why we did the conscious decision of breaking backwards compatibility and moving to native ASP.NET Style objects to implement control styling. We realized that this may be hard for existing customers, but we believed we did the right thing as the control is much more usable now.
The empty values support was another pain in the neck. The RadDateInput control had a design flaw that used the MinDate as an empty value. Again this unintuitive behavior caused so many bugs and so much grief to new users, that it had to go. The RadDateInput control in RadInput 2.0 has proper support for empty values and its SelectedDate property is now of a nullable DateTime type. This had to be changed for RadDatePicker too: had we left it as is we would have done much to help customers as most of them used RadDateInput as a part of their datepickers.
Again, I apologize for the pain we have caused to both you and other existing customers. I hope it was all for the better. I would like to offer our help in your migration process: we can even post the lessons learned here so that they help other customers facing a similar problem.
Kind regards,
Hristo Deshev
the Telerik dev team
Instantly find answers to your questions at the new Telerik Support Center