Precisely Speaking

General Category => Big Thoughts / Cool Ideas => Topic started by: precisonline on April 27, 2007, 01:09:41 PM

Title: Managing Customization
Post by: precisonline on April 27, 2007, 01:09:41 PM
A few questions for my esteemed friends and guests:

1) How do you manage change in your software application so as to a) provide for the needs of the user base, while b) not closing your upgrade path?

2) What works well about this strategy?

3) What doesn't work so well with this strategy?

I am aware of the party line of how several vendors approach the problem, but I'm more interested in the thoughts of individuals who face this kind of thing on a daily basis.
Title: Re: Managing Customization
Post by: Tom Pellitieri on April 30, 2007, 10:23:53 AM
Where possible, we try to integrate our custom software as much as possible to avoid upgrade problems.  We also maintain a list of local modifications.  For example, Prelude's Product Lookup program prompts to ignore single letters.  We use prefixes to identify products from a given vendor.  Since we are a distributor for one vendor, that vendor's prefix appears on over 60% of our products!  We copy Prelude's program to our User Forms and add a check to treat the vendor's two-letter prefix as a "single letter".  When we recompile, User Forms will override Prelude's base software.

We also try to keep as much coding in SB+ as possible.  This seems to avoid many problems with upgrades to the underlying database (UniData/UniBasic) and Prelude's software.

We also use our company abbreviation as a prefix for all SB+, file and program elements we create.  That way we can quickly find our mods and local files easily, which helps avoid process name overlap.

Generally, all of this works well for us, except when there's a Major revision.  The upgrade from Pick D3 to UniData took some doing, obviously, but some quick & dirty patches still exist in our code.  For example, we had a lot of EXECUTE "SP-ASSIGN ..." statements in BASIC programs that got changed to complicated "SETPTR ..." statements.  We have since created a subroutine call to handle this, but the SETPTR commands are still out there.
Title: Re: Managing Customization
Post by: sjoslyn on April 30, 2007, 05:14:01 PM
Hi Kevin and Tom,
Naturally my approach would involve PRC.  But even my Prelude customers -- the ones that DO have PRC -- have to go to some effort during an upgrade.  There are things I think they could do both using PRC and in just naming conventions and standards that could help.  Always including the company moniker helps alot.  The single thing that I would most recommend at these sites is to keep track of the major reason for a mod. If you are a PRC user this would be a good use of the project type code, but even if you're scribbling with crayon on a cocktail napkin, use a differnet color crayon or something, for the major reasons. 

I would want to know which changes were absolutly critical to the business and which aren't, and also which ones are specific to our business and which ones might get fixed by the vendor later on.  That way when you take a new release you can address the business criticial 'customizations' first, check the business critical bug-fixes that the vendor might have fixed, then take your time with the other ones.  This keeps the reintegration work that must be done during an upgrade from being this giant mountain of work that "all has to get done at once".

Naturally PRC can automate some of that phasing for you, too.  But I have lots of customers that don't avail themselves of a lot of the automatic work that PRC could do (or at least suggest) becasue they don't do any tracking of the KIND of work they are doing.

Title: Re: Managing Customization
Post by: precisonline on May 05, 2007, 08:54:02 AM
Good info, thanks!  So let me redirect from a slightly different perspective.  If you were designing an application where customization was to be not only supported but expected for the application, what design decisions might you consider to support that kind of activity?