The Old Joel on Software Forum: Part 3 (of 5) - Web-application and support for customizations

Web-application and support for customizations

We develop a number of web-applications (both COM+ and J2EE) and we're facing some contractual issues as of late that pertain to future versions and support for CURRENT customer customizations of code.

To clarify, we have some customers that are either modifying existing code (XSL changes for presentation and workflow desires) or creating new code (custom objects that interface with us via SOAP or API, custom pages that invoke standard POST/GET events to our application). As of late, as part of the legal language within a Service agreement, they are trying to work us into a corner where we will GUARANTEE that any and all product customizations (not limited at this point) will be supported for X number of years.

While I can understand the reasonable need to preserve compatibility at an API or schema-level, I'm really not comfortable throwing a total canvas on compatibility beyond that (for obvious reaons that escape the legal interests involved).

By chance, anybody here know how CityDesk or FogBugz handle this? What if a customer were to change an ASP page, even renaming it, to implement a custom feature. Given the number of INCLUDES, how would you even go about preserving compability? I'm sure there has to be some reasonble policy that balances backward compability with the freedom to make changes within discrete tiers of a web-application.

Many thanks for the feedback.

adk
Tuesday, January 27, 2004

Support anything they want so long as they'll pay $XXX per hour for it...

GiorgioG
Tuesday, January 27, 2004

Agree to their request for infinite support. Write an interface API to your real API. Make sure to put in plenty of wait routines to slow things down. Encourage them to move to the new API to improve performance.

Devious
Tuesday, January 27, 2004