“It is not enough to know how; it’s the when that is key.” With all projects, at some point in the development cycle problems arise.(1) When they do, questions of refactoring or porting should land on your shores. Often simple bug fixes or in-language refactoring is enough to resolve the issue; however when the impact crosses a critical threshold the answer is to port.
Port:
noun: a town or city with a harbor where ships load or unload.
verb: to transfer between two locations or environments
When it’s not right: port(2)
Porting software can be a major endeavor. Prior to this action a 5 part assessment should be made:
- Will this software module be in use for the long term(3) (e.g., will it exist in code deployed in the field; what is the life span of that product?)
- What is the criticality of the error? Is it: life threatening, product unusable, product behavior degraded, or is it a minor usability issue?
- What are the other issues facing the product and their criticality?
- If fixed now in-language will a later porting be required?
- What is your deadline?
Assuming that the metrics for 1 ~ 4 are high enough, and assuming that there is enough time before your deadline, it is time to port.
Estimating port fees
How do you estimate the time it will take to port your module, e.g. what is your “port fee?”(4) Ask yourself the following questions:
- How long did it take the first time around; of that time how much was spent on determining what to do versus implementation?
- Is the new language better suited for the implementation?
- Is there existing testing infrastructure and can it be repurposed for the new environment?
- Is the module unique or similar to existing code in the new environment; e.g. how well do you know your new environment?
The last question, how well do you know your environment is key. If you are just starting out in a new environment, the recommendation is to learn on non-critical applications. Learning an environment should never be a high stakes game.
Footnotes
- Problems can
- arise: e.g. float up from the buried issues in a poor design
- fall: e.g. come from outside sources as new information or requirements are given
- saunter in from the side: e.g. issues of integration with teammates
All in all, problems are three dimensional in nature
- Assuming you are moving forward, port is left.
- Stones from pyramids and other monuments have over time found their way into other construction. It is possible that stones from the pictured are part of someone’s house. When determining if a software module will be in use “for the long haul” it is not enough to look at the full systems but all the stones that make it up.
- While free trade ports are a hot topic in economics, they do not exist in software.