Cox, Bruce wrote:
Greg,
Roger, I hope you won’t mind if I give some of your interesting ideas a
bit
of a reality test.
In
summary:
For
us, changes are usually business driven and decided on cost, and, no,
it makes
little or no difference what kind of change it is.
In
exhausting detail:
At
the USPTO, [a great wealth of experience is briskly presented]
So, for USPTO, it seems like change management is costly and,
given the nature of the challenges, a "silver bullet" solution is
almost certain not to exist.
I think the next big breakthroughs in software engineering that will
help are a few years away but can be somewhat foreseen: advances in
(the practical application of) type theory will eventually be relevant.
A USPTO customer downloading XML files and feeding them into some
process can be thought of as building a single statically typed program
from various ambiguously typed parts -- the USPTOs services combined
with the customer's own code. That is, if we look only at the source
code of the customer's programs, we can't infer a static type for them
but if we get a complete type declaration for the USPTO input services,
then the customer's programs' types can be inferred.
If we eventually standardize a representation for type signatures, then
customers can abstract such representations away from their downstream
software and "register" these type signatures with, say the USPTO.
The point of this is to help USPTO better estimate the costs of changes
and to accelerate testing: If a proposed change can be trivially
type-checked against registered uses for the data or service, that can
accelerate R&D for changes -- at least some kinds of costs of
proposed changes can be spotted earlier than they would be without
application models registered by customers. Testing is similarly sped
up: there's no need to run a test on a program that is known to not
type check.
I'm not making any very specific commitment about the definition of
"type" in this prediction :-)
-t
|
