BA372 - Portability
- Porting:
transferring a software product to another platform.
- Platform / Interoperability:
- Hardware.
- OS.
- Server.
- Client.
- (Human) language (should TeachEngineering have an
English/Spanish switch?).
- 'Usership' ==> open source vs. proprietary.
- Organizational and regulatory environments (e.g., MA-MS
ODF controversy).
- Hohmann (p. 115): "Marketects
and tarchitects alike often pursue portability with a fiery passion."
- Development mostly on Windows.
- Significant use of Linux shell scripting ==> Windows
batch file scripting.
- Linux crontab ==> Windows scheduler.
- ==> some double code base.
- All open source except one or two (very important)
development tools.
- '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: inherent tradeoff for
platform-independence?
- '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 on multiple platforms.
- Management of multiple release cycles.
- Portability does not compensate for a poor product.
- Good products do not necessarily HAVE to be portable (see
Pfizer/Sun
example on p. 118).
- Carefully compare revenue/platform with cost/platform.
- Technologies (generic tools) have a higher need/opportunity for
portability than applications (p. 117).
- 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'
(standard-compatible) code.
- Nonetheless; often minor code variations across platforms.
- Some products provide platform-independent code
libraries; e.g., Galaxy by Visix (no
longer in business).
- 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).
