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)
Copyright © 2016 Tex Texin. All rights reserved. 3
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
Copyright © 2016 Tex Texin. All rights reserved. 5
How software project estimation works
Copyright © 2016 Tex Texin. All rights reserved. 6
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
Copyright © 2016 Tex Texin. All rights reserved. 7
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
Copyright © 2016 Tex Texin. All rights reserved. 8
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
Copyright © 2016 Tex Texin. All rights reserved. 10
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.
Copyright © 2016 Tex Texin. All rights reserved. 11
Gather Product Requirements For Review
-Globalization requirements
- Requested fixes, features, enhancements
- Targeted regional markets
-Also
- Non-globalization requirements
- Product maintenance
- Infrastructure upgrades
Copyright © 2016 Tex Texin. All rights reserved. 12
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
Copyright © 2016 Tex Texin. All rights reserved. 13
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)
Copyright © 2016 Tex Texin. All rights reserved. 14
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)
Copyright © 2016 Tex Texin. All rights reserved. 15
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
Copyright © 2016 Tex Texin. All rights reserved. 16
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.
Copyright © 2016 Tex Texin. All rights reserved. 17
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
Copyright © 2016 Tex Texin. All rights reserved. 18
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
Copyright © 2016 Tex Texin. All rights reserved. 19
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
Copyright © 2016 Tex Texin. All rights reserved. 20
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
Copyright © 2016 Tex Texin. All rights reserved. 21
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
Copyright © 2016 Tex Texin. All rights reserved. 23
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.
Copyright © 2016 Tex Texin. All rights reserved. 24
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.
Copyright © 2016 Tex Texin. All rights reserved. 25
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)
Copyright © 2016 Tex Texin. All rights reserved. 26
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.
Copyright © 2016 Tex Texin. All rights reserved. 27
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.