BA372 - Portability
- Porting:
transferring a software product to another platform.
- Platform:
- Hardware.
- OS.
- Server.
- Client.
- (Human) language.
- Etc.
- Hohmann (p. 115): "Marketects
and tarchitects alike often pursue portability with a fiery passion."
- 'Claimed' motivations to port:
- Support of multiple platforms provides access to additional
markets.
- Support of multiple platforms shows that we can meet customer
needs.
- portability paradox:
"Customers choose a platform because
of its unique features and perceived benefits, but most portable
applications are explicitly designed to avoid platform-specific
features."
- Problem: would
you consider this a true paradox?
- 'Real' motivations to port:
- Writing portable software is interesting and neat (compare with
resumé-driven design).
- One or two, early key customers want the tool on different
platforms (pressure to have income causes early porting).
- Portability is ALWAYS
about money (p. 118):
- Train developers on multiple platforms.
- Purchase and system maintenance of multiple platforms.
- Development, testing and QA.
- Management of multiple release cycles.
- Portability does not compensate for a poor product.
- Good products do not HAVE to be portable (see Hohmann/Pfizer/Sun
example on p. 118).
- Carefully compare revenue/platform with cost/platform.
- Technologies are easier to port than applications (p. 117).
- G. Moore (1991) Crossing the Chasm: first (technology) mover
grabs the lion's share of the market.
- Technologies are mostly built with portability in mind:
- modular, stubs for drivers, configuration files, etc.
- How to port:
- A priori instead of ex post; i.e., build it portable in the
first place.
- Use interpreted languages:
- Need an interpreter for each platform.
- Single code base.
- Compiled languages:
- Compiler for each platform.
- Only write 'portable,' 'cross-platform' code.
- Nonetheless; often minor code variations across platforms.
- Some products provide platform-based abstraction code
libraries; e.g., Galaxy by Visix (no
longer in business) or Qt.
- Write standards-based codes; e.g.,
ANSI (Standard) SQL rather than Transact-SQL (Microsoft) or PL-SQL
(Oracle).
- Use XML for data communications.
- Matrix of pain (p. 121-126):
- Multiply the various platforms into a theoretical number of
combinations to support.
- Delete all impossible and unlikely combinations.
- Rank order.
- Decide:
- Pareto
chart of customer configuration distribution.
- (shows you what % of customers uses/wants each of the
combinations).
