Journal johndiii's Journal: Assumptions... 13
Suppose that you have a collection of items, each containing a collection of subitems (which may be empty, but in practice almost never is). Something like this XML representation:
<Items>
<Item ID="1">
<Subitem ID="S1" T="13"/>
<Subitem ID="S2" T="18"/>
<Subitem ID="S3" T="10"/>
<Subitem ID="S2" T="12"/>
</Item>
<Item ID="2">
<Subitem ID="S3" T="14"/>
<Subitem ID="S4" T="16"/>
<Subitem ID="S5" T="12"/>
<Subitem ID="S2" T="12"/>
</Item>
</Items>
The subitem IDs are assigned by some other system. It has a vague notion of the Item/Subitem structure, but assigns the IDs based on its own rules and processes. Would you assume that the subitem IDs are unique across multiple items? Or even within a single item?
And how late would you be prepared to stay at work to fix the result of a mistaken assumption (in this case, on someone else's part
well (Score:1)
How late I would stay would involve a rather complicated calculation involving a number of factors boiling down mostly to how necessary it was to keeping my job and how badly I wanted the job kept.
I would try not to assume anything... (Score:2)
Even if you are talking about products, there is still a case where subitems could be shared among items. Case in point is the local home improvement store. Both the plumbing department and the gardening department carry items for drip irrigation.
If the specification was designed by a C programmer, I would assume that subitems could be shared among items (multiple
Re: (Score:2)
I usually... (Score:1)
As far as how late would I stay, it really depends. But to give an idea, of the 6 years I have been at my current place of employment I have likely worked less than 5 hours of overtime.
Assumptions (Score:2)
Without direct control of the assignment process or a well-written spec that describes the assignment process, it is dangerous to make any kind of assumption.
No.
No. Even in your example you show in Item 1 that there are 2 S2's. They have unique values but not identifiers. There is no guarantee that the values shall remain unique, either,
not unique in any scope? (Score:1)
Stay late? (Score:1)
I leave early at 6 to 7 pm every night
Depends (Score:2)
If this is a bug in a release three months from now then it goes into the schedule bucket and it is fixed when it is fixed.
Re: (Score:2)
Last night was not too bad, though; I was home by 11pm.
If we change ... (Score:2)
We're asuming that ID really means what it says. If, on the other hand, instead of calling it "ID", the original author had written something like "Sample Weight", then we wouldn't expect uniqueness - they'd be like detail records in a master/detail table relationship.
This just proves 2 things - (1) contrary to Shakespeare*, names are important, and (2) people who think xml is the be-all and end-all should be shot :-)
People who believe "A rose by any other name would smell as sweet" should check out t
Re: (Score:2)
I suspect that the people who designed our product would be some of those that you would have up against the wall.
Re: (Score:2)
What I've found is that people who *should* know better check their "brainz" at the door when it comes to xml - "all we have to do is use xml" ... as if that magically solves all problems.
Maybe xml 3.0 will have some magic pixie dust ...
Good catch on finding the problem in the original app, btw :-)
Hm (Score:2)
Does the answer to this question actually make any difference in whether one actually stays late?
If so, I suppose it depends on the environment and the person. e.g. where everyone is helpful and supports each other (and , on the other hand, they understand if you can't help out this time), vs. you're getting screwed by having to fix someone else's mess (in which case "w