Advice on Walking Out of a Job

As much as people like to knock Slashdot you can't find a much better site when it comes to hearing stories of programmer lives direct from the trenches. The best posts are always the ones that are relevant to a wide range of developers regardless of background and relate to work experiences rather than specific technology. A good example of such a story was the recent Executing a Mass Departmental Exodus in the Workplace?. There were lots of great posts in that thread and just highlighting the top 3 or 5 (IMHO) doesn't do justice to a number of the posts but here goes anyway

1. Reality
   
   
2. Don't flee - work properly: priorize, escalate
   
   
3. Be Machievelian about it.
   
   
4. It's a small world out there
   
   
5. Re: Result (aka Loyalty and Business do not Mix)
   
   

#

The AI Winter and the Nature of Failure

Reading Martin Fowler's Bliki I found his post entitled What is Failure? where he states

The Standish Group's CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001's figure of 28%.

...
The chaos report defines success as on-time, on-budget and with most of the expected features. But is this really success? After all Windows 95 was horribly late yet was extremely successful for Microsoft's business.

...
I would argue that it's the estimate that failed. So the CHAOS report isn't chronicling software project failure, it's chronicling software estimation failure.

This post reminds me of another that I discovered after stumbling on a link to a description of the AI Winter. This post from Steve Vere to comp.ai in 1992 points out another way that success and failure can be miscalculated when looking at software projects

lots of money was spent on several prototype systems, of which nearly all worked. The problem arose when it actually came down to using the systems. The management here has no concept of how it runs its processes, because they're held responsible for money, schedules and people. Therefor they see very little need to "fix what ain't broke." They have also been conditioned not to take a risk. With this kind of corporate culture, AI expert systems just couldn't be implemented. They wouldn't take the risk, change the work, or spend the money to implement the prototypes. Therefore time after time the systems died on the vine. SO that after a while it looked like a lot of money was being wasted on a technology that didn't work. When I looked at the data I found out the technology was working they just weren't using it.

It's review time again in the B0rg Cube and as usual I am introspective about the nature of success and failure when it comes to projects.

#

Why Derivation by Restriction Should Be Avoided in XSD

Fumiaki Yoshimatsu wonders why I advised against using derivation by restriction when authoring schemas using W3C XML Schema. Well, lets start at the beginning by asking what purpose an XML schema serves. In my experiences as a tester and now program manager working on XSD there have been two broad classes of usage for XML schemas (a.)As a way to create strongly typed XML and (b.) a way to create a contract between the producer and consumer of XML. You could probably subdivide (a.) based on the folks that just use an XML schema as a way to map XML to their data models but I think that's just a refinement. So now let's go into why derivation by restriction is bad in both scenarios

1. STRONGLY TYPED XML: People who want strongly typed XML usually want a post-schema validation infoset where an XML infoset has been annotated with type information. Specifically they typically want the leaf nodes (i.e. text nodes) to have datatype information which map to XSD simple types and sometimes want a particular tree structure (e.g. person element is the parent of the name and ssn elements in a particular subtree) to be labelled with a name which maps to XSD complex types.
   
   Having just simple and complex types is enough to perform most operatations one would want on typed XML infosets and is satisfactory for solutions that want to map XML to other domains like objects, relational databases or GUI widgets. Of course, this breaks down when the mechanism used to create typed XML infosets adds concepts to its type system that have no analog in the target domains. One such concept is derivation by restriction for complex types (and simple types to a lesser degree).
   
   How would you model a concept such as the fact that an employee can have a work-phone and optional home-number but a contractor which is derived by restriction from employee restricts away the optional phone-number field so that it never occurs in non-XML domains? This is practically impossible to do in any OO system I am aware of without significant alterations or massive hacks the same goes for relational database systems.
   
   Since XML data is typically the bridge between relational database back ends and object oriented languages uses for processing said data one should not add a layer of impedance mismatches in what should be the bridging layer.
   
   
2. SCHEMAS AS CONTRACTS: Many organizations have embraced XML as the answer to their information exchange problems. Typically such entities exchange information in environments that are heterogenous and it is unlikely that the same technological solutions are in place at every end point. In plain language it is unlikely that each organization is running the same OS, using the same programming language and the same version of a particular XML processor.
   
   Thus people exchanging XML documents who want to first ensure that the incoming document is in the correct format will most likely be using different validators. This means that there will be differences in the behavior of schema validation either due to bugs in implementations or due to misinterpretations of the spec. Derivation by restriction is the most complex part of an obtuse spec, the most buggy (take a look at the W3C XML Schema comments page and the most prone to misinterpretation even amongst members of the W3C XML Schema working group.
   
   Using derivation by restriction correctly and being aware of all its ramification often takes a language lawyer with arcane knowledge of the multilayered aspects of a cavernous spec. Even then there is no guarantee that the schema validator of either the producer or consumer of the document would have been developed by people as knowledgeable of the spec as this fabled language lawyer.
   
   Since exchanging XML documents should be about interop one shouldn't detract from this by using a complex aspect of a complex technology which may result in both parties having to settle on the same platform/XSD processor thus defeating one of the gains of using XML in the first place.

#


--
Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.