set/get functions in class.

This is actually a mail trail of a question that Ashish Khare asked me. With his permission I am putting parts of the discussion in this blog entry.

The question was

I am looking at a class which has 4 ints declared as private and for each one there is 1 Get and 1 Set functions which is public.
When all these ints are exposed ( indirectly ) to external world, why should I declare them as private? I could have all the ints as public with no Get and Set functions. What do you say? Is there any advantage in the way class is existing now ( private variables with Get and Set functions )? Is there some better way of designing a class if requirement is such that you need to get and set the variables.

My answer to this question was

In effect, there is no encapsulation in class. Only place where it helps is in debugging. If value of some variable is getting changed. Then you can track where it is getting changed by putting a break point on 'set' function.

Ideally reevaluate why you need the class and especially 'get' functions. Follow the principle of 'tell, not ask'. See where and how are you using those get functions. (.e.g 'ask') and what operations are done on those values after 'get'.

Ashish replied with :

Got ur point but basically this class is related to some database records where you often need to get and set values. For example, in a optimization study some parameter can vary from 5 to 10 with an increment of 1. So in first run, I get the value ( which is 5 ). I use this value, analyze the problem and see if criteria is met or not. If this is not met, this value is increased by 1 and now it needs to be set back as some parallel tasks also need the updates value from the record. Likewise the flow continues. I guess, in this case, I can't get away from get and set calls ( or make the variables public )!

From the words like 'I get the value ( which is 5 ). I use this value, analyze the problem and see if criteria is met or not. ' one can say that the design is in 'ASK mode' rather than 'TELL mode'. My reply was :

Lets look at your problem again. "So in first run, I get the value ( which is 5 ). I use this value, analyze the problem and see if criteria is met or not. ". That is ASKING. " Can put the "analyse" part(fully or partially) in a member function of your class and then call the function? That is "TELLING". Then you don't need 'get'. You can have another function "increment" to increment the current value. Then you can avoid explicit set.

Try to switch "TELL" mode than 'ASK'. Its not THAT difficult. You will find that the code generated is lot simpler to maintain and change.

From his response, I think he got the point. From my experience switching from 'ASK mode' to 'TELL Mode' is a major and important step in practicing Good OOD. Once you switch, design, code, maintaince, etc becomes a lot easier. Try it.

PS: One of the guidelines from my Mechanics of Code Review ppts was to question the need of every 'get' function.

Martin Fowler has written one of the best articles on this subject (Data Access Routines).

Lets create a check list

Lets create a check list

This is Last of the 3 ideas that I posted in 'some ideas that just don't work'. Check lists were favourite of ISO 9000 (at least the ISO 9000 implementations, that I have seen).

If your code is bad, customers are cribbing, create a check list for coding errors, check list for spec documents, check list for testing, check list for code review, check list for release etc etc etc. Generally check lists start small, grow really fast. Soon they have of life of their own and they just refuse to die. Soon you are faced with huge check lists which are impossible to follow. Worst, you have a check list which is irrelevant, but you have to make a tick (else ISO auditor or internal process people catch you). So you have to follow some stupid, rigid outdated rules just to be 'compliant'.

Lot of times check lists are used as replacemen for training. Good developer, development practices cannot be replaced by training. Good coding practices should become a habit of developers and should not remain in some check list that no one believes.

Unfortunately, I have seen 'lets create a check list' syndrome too many times. May be it comes from the fact that there is problem, and you have to show to your management that you are doing something about it. Creating a check list something you can show, its tangible. Better practices and training are intangible and take time to show the results. I think thats root cause of 'lets create a check list' syndrome.

Lets use a project metric to measure individual performance

'We need to distinguish between good and bad developers and promote good developers. We need an objective way to do this. We want to tie the compensation for developer to its performance. We need an Objective way to measure Developer Performance. '

A very nice and persuasive argument. Usually this ends with 'lets use a project metric to measure indivisual performance. Lets use bug/KLOC'. Remember 'what gets measured gets done'. Problem is it gets done even if it is harmful to overall goal.

Combine these two facts, and results are not difficult to predict. Developers will try to minimize bugs/kloc even if jeopardizes the project. Simplest to reduce bugs/kloc is to increase KLOC. So cut/paste instead of reuse. Initial bug/KLOC figures look good. Overtime, the project will be a mess but by then original team is out. Any other metric like time to implement a feature, bugs per feature, bugs per module all such combination result in bad metrics for measuring individual performance.

Obviously, Slowly your good people will leave, because they try to do right thing for the project and rather than get rewarded, get punished for it. The Company is on downward spiral.

It reminds me of Dilbert comment 'How to detect if your company is doomed ?', If you keep on hearing words like processes, metrics, ISO, CMM etc., your company is doomed. There is a grain of truth in it.

Illusion of "We need some more processes. Then everything will be alright "

Lets look at why this doesnot work.

First Processes have to be people Centric. Any process implementation that ignores people or ignores people instincts is doomed to failure. Especially when the company (or departments) starts thinking if you have good processes you can replace developer X with developr Y without any impact on project. THAT NEVER WORKS.

Ususal one can define only 80% percent of process/policy. There are always some exceptional cases, which are not covered in the process documentation. The company has to be give enough leeway for the process implementers to take common sense decisions. Otherwise, for every exception company has to change the process and keep on documenting the exceptions. Soon it becomes a huge task and lot of time/money and energy is spent on bean counting rather Software Development.

From then onwards its a downward spiral. Good Developers and Managers leave, managers interested in joining committees and discussing things to death thrive, productivity drops and attrition increases, employee morale goes down. The tide cannot be changed by giving better salaries.

Hence People are most important and only People centric processes work.

some ideas that just don't work in software development

"The definition of insanity is doing exactly what you did before all over again, but expecting different results this time.". I don't remember where I have seen this quote first but I really liked it.

In last 7 years in Software development I have seen few ideas which are already tried and failed. But invaribale after some months or years some one comes up with the these same ideas AGAIN. Again it fails. Cycle repeats few months after. Its CRAZY but it happens always.

Some ideas I have encountered and which always fail are

1. We need some more processes. Then everything will be alright.
2. Lets use a project metric to measure individual performance (e.g. bugs/kloc, LOC/per day, bugs reported /day etc are the favourites)
3. Lets create/define a check list to ensure that all steps are followed by everyone.

Looks very sensible on first read. Problem is it almost never works in practice !!!

Why ? In next few blogs I will try to explain (from my point of view) why it doesn't work in practice ?

The Quotes I liked - Software Development

1. Computer science is not the same as Software Engineering.

2. "First make it work, then make it right." OR "Make it work, Make it right, Make it fast"- Kent Beck (I think)

3. "In my experience, the customer doesn't know what he wants until you don't give it to" --David Brady on the XP Mailing List


Update - I have created presentation from More such quotes collected over years and its now on slidshare 

The Quotes that I liked - General

These are some of my favourites quotes. Usually I use one of them as signature on my mails.

1. To attain KNOWLEDGE, Add things every day;
To attain WISDOM, Remove things every day.
-- Lao-Tse

2. "You ordered a first-rate article and you must be content to pay the price"

-- Joseph Clement (engineer, corresponding with his client, Mr. Charles Babbage)

3. "The definition of insanity is doing exactly what you did before all over again, but expecting different results this time."

4. Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning. --Albert Einstein

Update - I have created presentation from More such quotes collected over years and its now on slidshare 

Just starting

This is my first step into the world of blogging. I keep reading excellent blogs by Martin Fowler, Larry Osterman etc. Which inspired me to start my own blog.

For the start at least I am using it as place to pen random thoughs, ideas, links and articles that I have found etc.

For those who want to know, little bit more about me. Please check my page at http://www.geocities.com/nitinbhide