The Gladiator

Often in every other project, we can hear the following whispers..at times they get too loud.

• Developers: We are not getting requirments right. Typically the expecatation is from requirement gatherers.
  
• Requirement gatherers: Customer is not able to give requirments clearly. Typically expectation is from customer.

So the flow usually is from developers -> requirement gatherers -> customers. This happens on development projects.

You may note I have not mentioned business analysts/functional/domain experts. You can get such experts on a project only theoretically. Practically you wont get them and dont need them either.

There are multiple aspects to this problem:

• In today' s business scenarios, requirements are never complete. So dont expect as such. But dont accetp ambiguous requirments either. Ambiguity is removed by capturing requirments in code form for developers and non-code form for customer. (FIT) looks like a good starting point.
• Even if you have domain experts if they dont have the skill of capturing requirements then all their knowledge will not help. We must realize every project is to add business value. If business analysts try to have this aim uppermost, many thigns will start falling in place.
• Develoers have to change their mindset of 'we are only gonna code'. Nope you are blessed to do much more than that. Start writing automated tests as verifiction that your code works. Also some of you will convert above FIT tests inot code form. Think and ask questions. Many of them may be silly. But ask and get the answers.

So we can see that close colloboration between customers analysts and developers is required as the first step. And second a change of mind set of all three is required.

1. Customers must be willing to put down in provide functional test specs in discussion with specs,
   
2. business analysts must be willing to learn more about the art of collecting requirments, writing functional tests (even in code form if possible) and
   
3. developers in automating their unit tests in code.

Posted by Deepak Surti at 7:07 AM | Permalink | Comments

Here's a sample of how I read. Basically how I approach. Please note that these are only
general tips and you will need to make changes as per your requirments.

Reading a Newspaper

The articles of interest for me are typically columns, edits and analysis types. (You may see
I have an Indian Express hangover :-). I typically just rush through current news. Suprisingly
I dont find anything really interesting to read on top pages. Because they are news. They are
information about what has happened. So just rush skim skip here. The same treatment is meted
out to sports pages.

Next I move on the more analytical pieces. Here my aim is typically

• Get main idea
• Register structure
• Either have zero or some awareness of details (this varies). (I will explain different detail awareness levels later).

After I have read an article I do this. At times I skip step 4 below as that may not be necessary. I do step 4 for those articles where my control was not to my liking.

1. Recall what is main idea
2. Recall the structure
3. Just look at each para and try to recall what it says
4. Find out how I must have ideally read (OPTIONAL)
   
5. Register a few difficult words by trying to deduce their meaning. ( I never refer the dict. I think thats the worst way of improving your vocab).

Phew so if you spend time like this daily for an hr or so on a good newspaper, its going to make a world of difference.

Reading a Comprehension Piece

Now now. Typically RC pieces are dealt with in an aptitude test. GMAT. CAT. SAT. Here first
thing is to have a base strategy for the test in terms of timings. So I have to operate under a time constraint.

So we move ahead under the assumption that you have a time limit set to yourself. But not being hyper about it. Next I have the following aim while reading an RC:

• Find out the main idea
• Find out the structure.
• Have some awareness of details.
  

Then after having read the RC I do this:

• Recall the main idea
• Go through each para to find out what it says
• In each para, I go through the details trying to get as much as I can.

Note that here I dont usually bother to recall the structure (thats already in my head and I also need to save time). Now going through the questions is simpler. Most answers are picked automatically. For a few you need to use elimination, go to the details, or simply find out what my friend Twisted says as 'that which sucks the least'.

Reading a Book

This is a new field altogether. Here the challenge is assimilation of more volume of material. Again the differentiating point is "What type of book is it". Why I want to read it.

So a technical book is read in detail in parts and skimmed in others. Novels are read for pleasure in detail. At times you just want to get the gist of the book. So you skim the entire book.

I try to see how the book is structured. If it has sections, I see what each section will try to tell me. Then I see what parts of those section appeal to me. And they receive treatment as such.

The trick is to treat a book as a continous series of small articles and to link up the ideas together.

Details Awareness

Zero: You dont care about the details.
Some: You know there is this detail. You can describe it (but not in detail).
Complete: You know the details.

Posted by Deepak Surti at 7:35 AM | Permalink | Comments

So many times there is confusion about java and its access specifers. Here’s what they mean once and for all.

Public: Available to all wherever you may be.

Private: Available only to me.

Protected: Available to my derived types.

Friend: Available to all who belong to my group (package) i.e. are my friends.

Naturally, if I make a class private it can’t be accessed by anyone except the class itself! Now trying make a class protected. Then it will available to only its derived types. But its protected and you cant derive a type. Hence classes don’t have private/protected specifiers. They have only public / friend specifiers.

However pick any class member and you can safely say it can be either public, private, protected or friend.

That’s good enough. But real java code will be a mix of public/friend classes with members at different access levels. The matrix is revealed below:

The following is a list of classes we have:

Class	Access	Package
A	Public	com.test
B	Public or Friend	com.test
C extends A	Public of Friend	com.test
D	Public of Friend	com.testother
E extends A	Public of Friend	com.testother

Lets see what members of A are accessible to what members of B, C, D, E. Classes B, C are in same package as A while D, E are outside of the package that A belongs to.

Non static members of A	Can be accessed by	Can be overridden by
Public	B, C, D, E	C, E
Protected	C, E	C, E
Friend	B, C	C
Private	None	None

Now lets apply the above to a friend class.

The following is a list of classes we have:

Class	Access	Package
F	Friend	com.test
G	Public or Friend	com.test
H extends F	Public of Friend	com.test

Naturally here I consider classes only in same package as F.

Lets see what happens here.

Non static members of F	Can be accessed by	Can be overridden by
Public	G, H	H
Protected	H	H
Friend	G, H	H
Private	None	None

Note that static public members of F can be accessed outside the package !

Posted by Deepak Surti at 12:48 PM | Permalink | Comments