Engineering Discipline Applies To Software Porting Too!
By Bill Porcaro, Ready-to-Run Software, Inc.
Let’s begin this examination of the process of software porting with a rhetorical question: What’s the difference between a software engineer and a programmer/analyst? A software engineer must be skilled in the science of engineering methodology from requirements to delivery. The programmer/analyst is someone who develops a program that performs a desired task. The properly engineered product can be turned over to other suitably skilled individuals to enhance, maintain, test and support while such may not necessarily be the case with the programmed application - especially as the complexity escalates.
Ask for an enhancement of a programmer and you might likely hear, "give me 5 minutes, I can make it do that". While asking for modifications of a skilled and experienced engineer should elicit, "give me a requirements document and I’ll turn out a design specification for the next release". The point here is not to elevate the role of the software engineer or to minimize or diminish, in any way, the capabilities of the programmer/analyst. The function of each job is, indeed, quite different. Rather, this contrast is made to underscore a disciplinary distinction that must be recognized in order to routinely deliver successful results in complex application development. There is no less a need in the porting of software across platform, technology or architecture. To do so is to proceed at one’s own peril while introducing unnecessary risk into a porting project. This paper documents the proper steps to follow in these projects while highlighting the caveats and pitfalls.
What’s Needed To Succeed?
Engineering discipline is the successful planning, implementation and delivery of a project using industry accepted practices.
The act of taking an existing software application that executes on one platform and getting it to execute as well or better on another is conventional software porting. Many times, the porting effort will uncover symptoms and related solutions that facilitate performance improvements on the original platform as well. Software porting all seems so simple: a couple of changes, recompile, link, smoke test and you’re done. A programming task it is! Well, not quite.
The problem with the programmed approach is that you won’t know when you’re done, if you’re done, what it will cost in terms of time and effort, and finally, the users will likely be uncovering showstoppers right out of the box. Also, the maintenance nightmares that can be caused and that appear much later ‘down the road’ are not always obvious – but can definitely be the highest component of cost and are usually not budgeted.
Software porting deserves the same careful planning and engineering practice as any development project. Is that too much to ask? Businesses need the ability to predict, with reasonable certainty, project costs and dates for project completion to support planning and to meet market demands.
When a project is in trouble, most of us have heard numerous excuses for the impact to delivery on time, on quality, or on budget. I have more than a few recollections of terse responses to the seemingly straightforward question "Are you on schedule?" When proper methodology is not applied to the task at hand, some of the common replies will include: "I have no idea how long it’s going to take me…", "the schedule wasn’t my schedule…", and, of course my all-time favorite, "it will be done when it’s done…".
How do you avoid these nightmares in a porting effort? The simple answer is to merely follow recognized engineering principles. It’s the same process and criteria used for any properly managed application design and development project. For example, avoid defining delivery dates before you have had time to analyze whether the dates are indeed reasonable for the work involved. You’ve heard or, heaven forbid, may have even said the following words yourself: "I need that capability for Q2. When can we start development?" Such a project is doomed for failure before one line of code is ported. Development activity should never begin until you fully understand the complexity and factors contributing directly to time and effort so that suitable management tradeoffs, if any, can be made.
Software engineering principles dictate that you begin by defining the project in plain and practical language during a REQUIREMENTS phase. For example, in simple terms, "We require support for platforms X and Y in the next release to meet market demands (list specific demands). Also, we must incorporate bug fixes and the top 3 customer requested enhancements to the current capabilities."
The next step involves structuring a mini-project, termed here ‘the analysis phase’, to take the initial requirements language and turn it into a successful project plan, including a FUNCTIONAL SPECIFICATION. The scope of the mini project varies widely based upon the actual requirements. The analysis phase may include feasibility, scope, prototyping, innovation, research, feedback and more. The goal of the mini-project, however, is always to translate the requirements into a specification and plan.
The biggest temptation and threat to project success is to bypass the analysis & specification phase. Who needs to take valuable time expending resources on such a mini-project? In fact, you told your team exactly what you wanted so why aren’t they just jumping in and writing and/or re-compiling code? However, any experienced and competent engineering manager will tell you that giving in to this temptation is quite deadly. The following words are huge red flags for a project that is likely to be headed towards trouble: "That’s way too much time to spend on specs, I know what we have to do, let’s just get started; we’re late already" and "I’ve got to fund two projects to deliver one! What am I paying for and going to get out of this analysis phase?" If you skip the analysis & specification phase, you may as well just open the checkbook and pray that the project gets done someday, in some resemblance to its intent.
Successful software engineering including the subset of porting to new platforms requires this analysis phase to be separated out rather than built in, i.e. a conscious decision must be made to invest in analysis & specification as a concrete, distinct step in which the resulting findings and plan are examined prior to moving ahead. If it’s built in, the decision to go forward with the project is a fait accompli without a full understanding of scope. The analysis phase must be well defined and constrained to target the stated requirements. This phase should never be minimized nor trivialized. When executed properly, the result is an accurate description and breakdown of the work, as well as a cost model in time, effort, tools and skills required to deliver. With this information, you can forecast the end date by plugging in a start date, team size and utilization rate. (I won’t elaborate upon utilization rate here but it’s an intriguing subject deserving a separate discussion.) It’s also the perfect time for decision makers to evaluate whether to go forward with the project at all, to review the alternatives and the assumptions, or to change the scope in order to meet dates, budgets, etc. It’s sure better understanding what you are getting into up front rather than as part of a project post-mortem.
How did the analysis & specification process accomplish so much? A small but focused project team or seasoned engineer took the plain, simple language documented during the requirements phase and then produced a functional specification and a quality project plan. They researched the tools and techniques required to produce the desired results. The project was broken down and each component was conceptualized, designed, and estimated. The analysis phase is then closed with the signing of the functional specification, and acceptance of the project plan. And, in doing so, you have cleared and secured the bedrock on which the project can be built.
Now it’s time to implement the actual port. The first step in a porting implementation is typically a top-down engineering design followed by code migration and related reviews using a combination of automated tools which analyze the source code for problem areas, code re-write and trial code compilation and linking. And you can expect it should go smoothly – at least, you have built the right foundation using engineering principles to minimize your risk.
But, at this point, it is important to remain cautious. The final common pitfall that can destroy the success of any porting or, for that matter, application development project is ‘scope creep’, i.e. the result of allowing a project to expand beyond the defined boundaries of the specification. Do not let the project exceed the stated requirements or written specification and project plan – at least, not without an acknowledged and budgeted adjustment to cost and/or time of delivery. The trick is to always stick to the agreed work with no new requirements. The manager should schedule frequent checkpoints to compare status to plan and choke off scope creep before it occurs. This is another example of how control and discipline will play a vital part in the outcome. Overall, the role of engineering discipline and solid management principles cannot be emphasized enough in order to insure a clear path for a successful software porting effort especially in the case of a complex migration project. Indeed, following proven process and methodology will pay huge dividends.
Bill Porcaro is the Vice President of Professional Services for Ready-to-Run Software, the industry leader in software porting and cross-platform services.
© 2001. All rights reserved. Material cannot be reproduced without permission of Ready-to-Run Software, Inc. Any reproduction, representation or use of the material provided herein without the prior knowledge and expressed written approval of Ready-to-Run Software, Inc. is prohibited.