Smalltalk is one of the very few development environments where developers get easy access to all the source code of all the frameworks they use. This comes in very handy when there are problems you need to debug and you need to step through the framework to figure them out. It also allows you to see how the framework expects to call your code.
Smalltalk also allows you to make changes to that framework. Environments like VisualWorks even allow you to keep your base changes in your own packages so that they're loaded in when you load the rest of your code from the version control system.
The problem with all of that is that developers begin to feel too free that they can change anything they want. If they don't like the colors of controls, they can change them. Do you want to add new options to the controls? Sure, go ahead. Do you want lists that format their contents into columns? Just write it. Many companies develop their own frameworks on to of the vendor-supplied framework.
It makes for an incredibly flexible system but there's one huge drawback. When you upgrade to a new version of the base, the vendor has made changes and now all of your modifications don't work. It's a long and painful process to find the pieces that are wrong and either fix them or re-write them.
I'm currently working on two upgrades for VisualWorks customers. Both of them have built their own frameworks on top of the VisualWorks framework. Both are encountering problems upgrading to the latest version because some very basic things have changed in the base. Normally, these are details that only the vendor needs to worry about, but when you build your own framework with intimate knowledge of how the base framework operates, you're going to run into problems.
I don't really have a good solution for these customers except to fix the problems as I come across them. It would have been nice if they didn't have this strong dependency on the base but given that they do, I can't really change that. They just have to understand that it makes upgrades more difficult and expensive.
Do developers in other languages have these problems as well? Do you need to make sweeping changes to your Java application whenever a new version of Java or one of your framework libraries comes out? Do you customize your framework libraries? Is this just a Smalltalk headache? Let me hear from you.
It's a common problem in Ruby too. People make frameworks over frameworks like Rails.
ReplyDelete...and then Rails changes in ways that are incompatible with the framework built on top of it?
ReplyDeleteExactly. There are many huge Rails apps running in production. When they want to upgrade the Rails version (for security reasons) it's sometimes a many-months, many-people project, a very costly thing.
ReplyDeleteDavid, we have same problems over here. I work in a Smalltalk inspired GIS Product named Smallworld (Image-based with a proprietary database supporting long transactions, language is Magik) Many customers have modified base code making upgrades hard. We try to follow some patterns (like method wrapping) to make upgrades easier. But still an upgrade is a headache. This is due te freedom we have and the limitations in extending the core framework. If only one can extend the framework by modifying code you will get this kind of problems. I expect similar problems in Java with byte-code injection, even harder to solve
ReplyDeleteIt seems to be an industry-wide issue.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete