MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] RE: OGC UoM Best Practices guidance
Gary -
Perhaps a bit off topic, but I hear the developers pain. That said, who is
running the show - the developers or the managers/policy makers? Perhaps
the issue you are pointing to is more one of culture than not wanting to
take the time to learn something new and correct. I managed a development
staff (young, old, geeks, gurus, strange personalities) for many years. I
gave them considerable freedom to be creative and be productive. BUT, and
I mean BUT, their performance reviews included how well they adhered to
very specific documentation and coding best practices, proper testing of
the code they developed, adherence and use of a significant set of
standard interfaces for our product line, and so forth.
Can you imagine if Oracle or ESRI or Microsoft or any other software
provider did not require their programmers/developers/engineers to use
their companies internal software development standards, including all
existing APIs, interfaces, standards, etc? There would be chaos.
This issue is even more on the front burner with SOA gathering so much
steam. SOA mandates the use of standards. SOA typically forces cultural
changes in the enterprise - like developers and managers working more
closely together to understand, define, and document business process.
Sorry for the slight rant, but at the end of the day, implementation of
standards is driven from the top down and the bottom up. Uptake is a
function of both policy (top down) and getting the job done (bottom up).
I would hazzard a guess that if corporate policy stating that a given
standard will be used is coupled with resources that made it easier for a
developer to implement, then uptake would not be an issue.
Cheers
Carl
> Carl,
>
> At least you provided examples!!!
>
> All kidding aside, it is not me that I am worried about here. It is a
> group that I tend to identify with, the journeyman software developer.
> Only with their support is adoption by a significant, traction capable,
> number of real vendors and government programs possible. Mandated or
> not, developers only build what they think is reasonable. (Think Ada,
> which was a superior language but essentially failed, in spite of
> government mandate.) So you will have to convince those who actually
> build software that what you are asking them to do is reasonable for
> their cost structure and schedule. I am in no way arguing correctness.
> You are correct, or at least more so than I am. I am pointing out that
> "correctness" can sometimes be so impractical that it leads to failure.
> So, if you want correctness to succeed, it has to both be reasonably
> easy to implement AND appear so to the journeyman developer. So, enough
> "theoretical correctness." We journeymen need to be provided with hard,
> real examples that meet specific functional problems. Otherwise,
> prepare for irrelevance. Standards geeks like Gary Ham and Carl Reed
> will just be ignored, and developers will go on building non-standard
> stuff that just "works."
>
> The good thing about the contents you provided is that there is an
> example for each of the schemas provided in the document. The bad thing
> is that there are so many choices. The chance that a development
> project will cover the gamut of the choices decreases exponentially with
> each extra choice provided. The only way to get around that would be to
> build some kind of very complicated "information hiding" software to
> make implementation of the choices easier. It is going to be
> interesting.
>
> Respectfully,
>
> Gary A. Ham
> Senior Research Scientist
> Battelle Memorial Institute
> 540-288-5611 (office)
> 703-869-6241 (cell)
> "You would be surprised what you can accomplish when you do not care who
> gets the credit." - Harry S. Truman
>
>