Although very noble goal for the user sake, and this effort needs to recognized and applauded by software publishers.
I wonder if this extra effort may place an excessive burden in each evolution, since a set of parameters, features unique to each customization need to be encoded in order to be carried forward.
Which makes non-sequential upgrades a big monster, not only to provision but to do any meaningful integrity testing.
Enterprise software, both legacy and new, handles upgrading customized software very poorly. Some software allows customizations, but forget about upgrading to a newer version of the base product without redoing all of your customizations. Some vendors take the approach that you shouldn't customize at all and, instead, use the software as it comes out of the box to avoid the travails of upgrading.
At Dovetail, we asked the question, “What if we could design our base product so that it was both easy to customize and easy to upgrade? Why had no one thought of this before? Or better yet, why hadn't someone done it?” It is a tough problem to tackle, that’s why. In other words, we saw this problem as an opportunity for us to solve and make the world a little better. We fundamentally believe that organizations should not accept that they should spend large sums of money to keep up to date with the latest technology or that they should just live with outdated technology.
When we started designing the new Dovetail CRM product, one of the primary goals we had at the time was to make it so that the software would always be easy to upgrade, even if it were heavily customized. We noticed that a lot of enterprise software (not just legacy software, but software that is being developed currently all around the world) handles customization poorly.
Thinking through the issues involved, we came up with a set of principles and practices that we thought would guide us through the process. These principles and practices fit into two categories:
* Quantity: Minimizing the amount of customizations that will be affected by upgrades of the base product and
* Quality: Minimizing the pain of upgrading certain customizations that will be broken by the base product upgrade.
We realize that there is no way to completely mitigate all upgrade pain. However, we can get rid of the vast majority of it and make the little pain that’s left easy to deal with. In the next section, we’ll discuss the principles and practices we’ve identified (and followed) for “upgrade-safe customizations” in an enterprise software product.
First Principle: Small Surface Area
How can I keep my customization code from breaking when I upgrade the underlying product?
The simple answer is: You can’t -- at least, not entirely. You can only minimize potential breakages. The first principle, “Small Surface Area,” deals with this problem. That is, keep the “surface area” (or “site” or “scope”) of customization small. By this, we mean that the place where custom code and baseline code intersect should be as small as possible while still being able to accomplish the...read more at
Blog Doing Math in FPGAs Tom Burke 24 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...