• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
 
http://giladmanor.blogspot.com/ giladmanor@yahoo.com
Hard coding, soft coding and configuration. Thoughtsabout system flexability 
 Written by Gilad ManorPosted on Thursday, December 4
th
, 2008
 Throughout my career I have encountered time and time again a basicpredicament, regarding the practice of configuration and customization of software products to the needs and requirements of its customers.Every employer I’ve worked for had his own approach, and philosophytoward the issue. And rather than discovering the “right way” of doing thingsI’ve notices the set of considerations and logic behind each approach. The focus argument is on applications that have to deal with business data. The handling of which determines the character of that particular business oraspect of business.For this domain we tend to see our products structured as such; we lay downthe foundations of the application as a rigid, hard to change baseline andthen layer it with supposedly easy to change pieces of software, where weallow changes and customizations per customer. The considerations one takes in mind, for the customization layers are:
•
Managing the customized code, and versioning it (if at all), a goodthing when customizations are done “at home”, extremely difficultto impossible if performed on site
•
Customizations that are either independent or require a build process,since the build process is an expensive overhead.
•
The ease of delivery of updates to the customer without disruptingthe customizations and adjustments he has there
•
 The speed and effort it take to get a baseline system to be fullycompatible with customer requirements
 
http://giladmanor.blogspot.com/giladmanor@yahoo.com
•
 The level of expertise, required from the staff that is customizing thesystem, this is important when you employ field engineers thatusually do not have the same background as your R&D.
•
System flexibility and deviation from baseline behavior, maximizingthis aspect widens the relevance of the product, this increasingsalesI’ve seen several approaches that I would like to address in this instance.
CODE BASE REPLICATION
 This is when for each customer, that has a contract for the particularsolution, a development team is allocated, and the entire code base isreplicated, usually from the closest customer project available.While the newly assembled team works on the new branch, the two codebases drift apart. There is absolutely nothing good that I can say about this practice, apart thatit works. The companies I saw that use or used this as their way of customizationallocate a hoard of developers on each customization task.No architecture is too holy so not to disrupt. Just make it work. And it does. This approach is of brought force, very costly in terms of manpower, but foragreements what are not in fixed priced (like in the old days before 2001),this is the best way to get things to work as fast as possible.
CODING BEHAVIOR IN XML
Coding behavior in property files, xml or any other textual format is a greatway of separating strategy from base line functionality.Adopting this approach, results get nice clean code; that does all the logic onthe one hand, and on the other, pure (configuration) data, stacked neatly inexternal files, describing choices in behaviors.
 
http://giladmanor.blogspot.com/giladmanor@yahoo.com
A disadvantage to this form of separation is that the application’s “base line”code actually has to include all the possible behaviors. When adding a newfeature, it gets coded into the base line and switched in a property file.Another aspect that may count as a drawback is the maintenance of theexternal property files. In all the projects I’ve worked on, it didn’t take longfor the number of external values to exceed the hundreds. It sometimes getsto the point where the development environments are so loaded withconfiguration that the development and testing are bogged down as a result.A workaround this splinter is to require of the base line code to be propertyresistant, meaning that in the absence of a property, the system would fallback to default functionality, without crashing. This, from my experience isnot a simple task.In some odd cases, I’ve seen elaborate structures of properties that bythemselves define a limited coding language. This, to my mind, is a miss,since the product does not benefit from a well formed product as theavailable scripting languages, the maintenance of the hippo scripting is veryexpensive, and so is the time one has to spend learning this uniquelanguage.
EXTENSION POINTS
 The use of extension points actually comes in a variety of flavors. Somesolutions I’ve seen, may in fact be categorized closest to the codereplication, others use advances scripting as I would discus later on.Building extension points into your applications base means that once youhave determined precisely, the path of a generic flow of events, you exposeyour data structure for tweaks and adjustments by the extendingimplementations.Determining these exit points in the baseline flow is far from trivial. It’s atask that requires superb understanding of the business domain.When different departments are responsible for the determination of theextension points and the actual customization, as is the case for most
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...