Friday, September 07, 2007

A little fun... Part II

Many of the thoughts as to why my response "didn't help" were very close.  The reason my response didn't help.....





they did not ask how to do what they needed to do, they asked a different question instead.



Here was the full response they gave me



Hello Thomas,

Thanks for answering me.

This doesn’t help me, since the indexes are not sequential. (they could be : 123298, 123400,122000), and I needed some more conditions.

So I used that one instead:

select * 
from (select ...,
(lead(id,1) over (order by id)) as nextTB,
id as TB,
(lag(id,1) over (order by id)) as preTB
where ARTICLEREF in (select articleref
where id=?)
and status ='AP'
order by id asc)
where id=:id


Now, the comment about the not sequential is not relevant - the approach I took did not rely on them being sequential. I would find the max(id) less than the one of interest and get three records starting there.

But, the bit about lots of predicates and such - totally missing.

This happens a lot - questions that are so ill specified or just not even close to what they wanted to ask - it wastes both of our time (my time, their time).

One commenter hit it on the head:

Writing specifications, asking what you mean, being concise yet complete - it is so important, yet seems to be the thing most lacking in many respects.  I think maybe this "agile" programming technique - the one where specifications and such are purposely "not firmed up" leads to this. 



Blogger Paul said....

Ouch, I can feel the agile wonks reel;-)

Interesting example Tom, thanks for sharing it. Makes you ponder
"concise yet complete"...

I think the problem is often one level removed. It's about the need for good judgement on whether the spec meets the "concise yet complete" criteria.

Or to put it another way - the anitpattern - it's the problem of "unchecked assumptions" at both ends of the conversation.

This is a great example because at first glance, the original question appears nicely concise and complete, and it's easy to jump to the conclusion that you understand the requirement.

But in hindsight the trap is clear, yet very subtle: the words imply "previous/next record in the result set" but the data/sample implies "previous/next id in an ordered sequence".

We are left dealing with a possible contradiction of implied requirements.

So at some level of consciousness, the writer has assumed you would understand it to be one or the other.

And as a reader, you are left to fill in the gaps a bit and make some fairly subtle assumptions. Its interesting in this case that depending on your bias to data or the written word, you may come up with a completely different understanding without necessarily recognising there is another possible interpretation.

Bottom line - agile process or not - I think the key to success as a reader and writer of specifications is to consciously check the assumptions you are making. Only then can you judge if the spec is "concise and complete".

Fri Sep 07, 07:59:00 PM EDT  

Blogger Stew said....

Problems with specifications (incomplete, vague, ambiguous...) have existed since I started out in 1981. "Agile programming" is not the first "solution" proposed. I remember Xerox was trying to sell us some highly configurable software in 1984, and a manager said: "the reason why I'm interested in your system is that I don't have to know beforehand what I want it to do." Even the Xerox salesman turned white.

Tom, your situation is special because you're answering questions: the ideal is one "round trip", the question and your answer. Within projects, I prefer an extended dialogue where I reformulate the requirement in context. I also try to show parts of the solution as quickly as possible as a sanity check. One of the difficulties with outsourcing, or the contractual approach in general, is that this dialogue is cut short.

Another problem is that the "requirement" is often a solution in disguise. So often, Tom, you get asked : "tell me what's wrong with my solution", and you have to ask what the problem is?

Sat Sep 08, 03:14:00 AM EDT  

Anonymous Toon K said....

>>Writing specifications, asking what you mean, being concise yet complete

Just recently a pretty good book appeared, that deals with exactly this...


Sat Sep 08, 03:49:00 AM EDT  

Blogger ZsP said....

I have the feeling that your last sentence is based on a classic misconception of agile planning/design. The agile attitude is not exactly about "purposely not firming up", it is about delaying the "firming up" to the last responsible moment. A slight difference, I would say!

Making a good spec is more the responsibility of the people involved in it than the methodology they develop in.

Sat Sep 08, 10:51:00 AM EDT  

Anonymous Robert said....

this points out the shortcoming of asking a (Oracle) technical questions in writing, I mean just look at the questions & the initial responses on

I didn't make a guess in Part 1 but the first thing was that I found the question hard to understand:

" extract a 3 records out of a result where the middle one is the query."

Sat Sep 08, 02:09:00 PM EDT  

Anonymous Anonymous said....

Seems to me that this is reflective of business writing as a whole. Specs, along with all business communications, need to meet the test of the 4 "C"s.

If your business specs (problem description) passes the test of the 4 "C"s, then you will be much more successful in your communication.

Mon Sep 10, 11:35:00 AM EDT  


<< Home