Refining Estimates for SW I18n - Unicode® Conference · i18n Agile internationalization Unicode conference globalization Created Date: 11/3/2016 11:52:22 AM

Tex Texin

Chief Globalization Architect

XenCraft

Internationalization and Unicode Conference IUC40

Refining Estimates for

Software

Internationalization

Abstract (Part 1)

Copyright © 2016 Tex Texin. All rights reserved. 2

This presentation will help senior managers validate development estimates for globalizing software and offer guidelines to either reduce the effort or prioritize implementation so that it can be phased into releases that maximize market value. The focus is on software internationalization, not localization processes.

Abstract (Part 2)


Developers generally make estimates in good faith. However, estimates are based on innumerable assumptions that should be reviewed. Software development is complex and there can be more than one way to approach solutions. The initial estimate is often made with urgency and with presumed optimal or ideal solutions. This presentation will give program managers, engineering leaders, and product managers insights into questions they can ask to validate software estimates and options that can enable more efficient delivery of international software.

Goals

-Offer general guidelines

- Questions to probe whether estimates are

reasonable

-Each case is different

- Not all of approaches may apply

- Not a complete list, other approaches can help

-For newer managers or for organizations

that don’t have more established

scheduling/forecasting practices


How software project estimation works


Manager says to Lead Engineer: Please give me an estimate for this project. • Here are detailed specs defining all requirements. • Tell me all the resources you need. I will get them

for you. • Let me know when the estimate is complete and

reliable in your expert opinion.

(Wait for audience to recover from doubled over laughter)

Creating an estimate

-(Good Quality) Estimates represent a sum

of many smaller estimates

-Innumerable assumptions are made for:

- Product requirements and expectations

- Existing code and design (portions may be

unknown)

- Rate of software development

- Allowance for unknowns and changes

-Often estimates are made in a rush

-Estimates can be influenced by agendas


Contributions to Inaccuracy

- Inaccuracy stems from:

- Speed, Assumptions, Unknowns, Aggregating

many details

- Contributions from multiple teams (and limited

communication)

- Estimates can presume optimal or worst case

development scenarios

- Influence by management expectations, politics,

and corporate culture, developer bias


Given more time, review, and reviewers, an

improved plan/estimate can be produced.

Refining Software Estimates

Refining Estimates

Compare estimate with:

-Past projects of similar scope

-Original cost of development

- Not that useful unless new software. However, if

estimate is similar or larger, it raises questions.

-Compare subtask estimates with past work

by the same team


Compare estimates with experience of past projects of similar scope

Ask for details and conduct review(s)

-Reviews are collaborative and not intended

to challenge development’s skills or integrity

-Review assumptions; promote discussion of

alternative development approaches.

-Review product requirements too. Reassess

now that costs are known.

-Avoid making “final” decisions at interim

stages of the review. Reconsidering

decisions, as information and understanding

improves, is healthy.


Gather Product Requirements For Review

-Globalization requirements

- Requested fixes, features, enhancements

- Targeted regional markets

-Also

- Non-globalization requirements

- Product maintenance

- Infrastructure upgrades


Establish the “Big Picture” to ensure open

discussion and perhaps unknown agendas. Otherwise, it seems some topics should not be discussed.

Product Requirements Review

-Check estimates are categorized properly

- Globalization not subsidizing infrastructure work

- Estimates not counted in more than one category

- Identify conflicting / crossing requirements

- Work on one requirement obstructs another

- Identify opportunities for synergy

- Resolving one requirement accelerates another

-Reprioritize cost-weighted requirements


Reprioritize cost-weighted product requirements.

But, we can’t change product requirements

-Product management is separate… We are

just the engineering team

-You can still discuss with your team and

document impact of high cost requirements

- It is part of justifying the estimate

- The information may influence product or senior

management

- The information may influence future

requirements specifications (or development

process)


User Interface Review

-Globalization estimates are typically based

on existing or proposed domestic UI

- Identify changes that reduce globalization costs

- Miscellaneous features (e.g. clocks)

- Redundancies (e.g. data repeated each screen)

- Sparse or dynamically adjusting layouts

- Simplified text, global images and formats (e.g.

numeric dates)


Review the User Interface to minimize the internationalization effort.

Legacy Migration

Globalizing existing applications can be a

substantial rewrite.

-Look for code patterns that can be replaced

with shared functions or reusable templates.

-Automate replacements where possible

-Code “wrappers” can bridge old code or

technologies (databases, platforms) to new

code where replacement isn’t practical, or

for expediency (and replace later).

- 80/20 rule is often a useful tactic


Automation

-Write code scanners (locate needed changes)

-Automate code replacement

- Commercial tools offer maintenance but may

require considerable customization.

- Home-grown 80-20 solutions can be effective but

less comprehensive.

-Add scanners to build procedures for longer

term benefit & establishing best practices

- Send results to a dashboard to avoid backsliding.


One-time and longer term automation and monitoring.

Platform Matrix

-Platforms (OS, browser, mobile devices,

social media, etc.) (and release versions)

are not ranked the same globally

- Global applications must also include local

regional platforms (not known in the USA)

- Regional platform versions can be ahead or

behind the USA and have different features

- Some USA versions may not be needed globally


Review platform demand in each market to

reduce testing and implementation costs

Operational, Management, Support Costs

Some features have extended costs - E.g. Passwords require utilities for resetting, customer

support, access controls, monitoring, and privacy

assurances

- Distribution & coordination of tasks affects costs

- Design changes can move effort from one team

to another, changing impact and total cost

- Change team assignments for more efficiency

- Elements that are backend and not user-visible

can sometimes be implemented post-release


Review support, management, and operational features and cross-team impacts.

Implementation Strategies

-Numerous small changes are common for

globalization; leads to overestimates

- Consider automation of code changes

- E.g. string externalization

- Focused, dedicated effort across many files

- Person or team makes changes, become experts

- Simultaneous changes in each file

- E.g. globalizing date, number, etc. functions together to

minimize compiling, etc. as opposed to serial approach


Review implementation tactics and affected file sets for efficiencies and cost reduction

Piggybacking

-Consider overlap with non-globalization

features

- Can globalization changes be made along with

other changes?

- If work is typically performed by different teams,

consider prescribing the exact changes so one

team can do the other’s work for greater

efficiency


Can non-globalization tasks include globalization work, or vice versa, to reduce total effort?

“We’re going to kickstart the earth’s

core!”

Core architecture vs Feature

-Applications are built on layers

- Core architecture supports outer layers

-Can core enhancements reduce I18n costs?

- Is resistance to changing core leading to higher

cost workarounds?

- Are core changes more expensive than fixes in

outer layers?

- Source file and bug fix histories guide risk

assessment


Tradeoff upgrading the core vs. application layers

Refactoring vs Fixing In-Place

Refactoring code for globalization can be

ideal, but huge effort with extensive testing.

- Analysis, design, deploy infrastructure, testing

- In-place fixing requires greater maintenance

over the long term, but can be expedient.

-Enumerate spot fix costs and technical debt

vs. refactor estimate to guide the decision.

-Decide for each application, not as a suite.


Evaluate spot fixes and technical debt, vs refactoring.

Revisit high cost regional requirements

-Generally, globalization features benefit all

markets. But some apply only to one or a

few markets.

-High cost features may not be of high

importance to the target markets.

-Evaluate their significance to sales/market

share, and possible exclusion or deferral.


Re-evaluate cost-weighted globalization requirements against sum of market impacts

Critical Path

-Review project sequencing

-Look for parallel development opportunities

-Do tasks match skill sets

- Perhaps reassign (team) responsibilities

-Add developers/ outsource with needed

skill sets, or lower cost /shorter schedule

- Some “specialists” produce working I18n code

that is not performant (applying templates

ignoring context)


Review project plan to minimize critical path.

Testing (tip of the iceberg)

-Evaluate manual vs automated testing

- Automation can be effective if programming,

updating and configuration costs are not

overwhelming

-Encourage in-house users to use native

language versions.

-Encourage QA to write non-English tests

- If localized QA is too costly, eliminate en-US

testing first.


Encourage regional testing early, often, everywhere.

Questions?

29 Copyright © 2016 Tex Texin. All rights reserved.

Tex Texin

Copyright © 2016 Tex Texin. All rights reserved.

Tex is an industry thought leader specializing in business and software

globalization services. His expertise includes global product strategy,

Unicode and internationalization architecture, and cost-effective

implementation and testing. Over the past two decades, Tex has created

numerous global products, led internationalization development teams,

and guided companies in taking business to new regional markets.

Tex is a contributor to internationalization standards for software and on

the Web.

Tex is a popular speaker at conferences around the world and provides

on-site training on Unicode, internationalization, and globalization QA

worldwide.

Tex is the author of the popular, instructional web site www.I18nGuy.com

Tex is founder and Chief Globalization Architect for XenCraft. XenCraft

provides global business consulting and software design,

implementation, test and training services on globalization product strategy and software internationalization architecture.

“XenCraft”, “TexTexin” and “I18nGuy” are Trademarks of Tex Texin.

http://www.i18nguy.com/

Documents

Refining Estimates for SW I18n - Unicode® Conference · i18n Agile internationalization Unicode conference globalization Created Date: 11/3/2016 11:52:22 AM