Announcement

Saturday, November 20, 2004

Body language of the Oraganization - My Interpretations : Part 2

I shall try to answer few more questions on what I will look for in a company during an interview. I could not write the blog very regular for last few months, because now I am working on most challenging project of my career.

Lets look at some of the questions.

  1. How much time you have to wait in Lobby ?
  2. How much time you have to wait to hear the written test result ?
  3. How much time you have to wait for interview to start ?
    Actually these two questions are related. In way, it tells you how much company values your time. If the Company don't value your time at the first instance, then the chances are it won't value your time after joining either. Probably you will be working 12 hrs day, probably also on weekends. Most of the projects, in this company, will miss the deadlines.

  4. What are the questions asked in interview ? Is interviewer judging your knowledge of arcane language syntax, your memory for API names etc. ? Did they ask you to write code ?
    I will be very uncomfortable if a team member in my team uses arcane language syntax regularly in his code. It means his code won't be readable and maintainable by the other team members. In the long run, it is bad for the project and for the company. But
    if the company doesn't understand this , then you will get blamed for delays.

    Understanding the concepts is more important that remembering API names. If you have worked in multiple technologies and languages and libraries then remembering API trivia is difficult and totally unnecessary. Usually now all the libraries have searchable help files. If you understood concept and design of the library, you can easily find out the function again.

  5. How was the furniture in waiting room ? (e.g. Fancy, comfortable, utilitarian, etc)
  6. If the furniture the waiting room is not comfortable, it is unlikely that your cubicles will be any better than that. Preferably ask them if you can see the work area.

Thursday, September 09, 2004

Body Language of the Organization : My interpretations - Part 1

Writing a blog entry after a month. When I wrote the last entry, I was in Munich, Germany. Now I am back in India and heavily involved in a new challenging project. Last one month was hectic and I could not write anything.

As I promised, this time I am going to give my interpretations of the Body Language Observations. Remember these are 'my interpretation'. You may not agree with those interpretations. Feel free to add your interpretations and comments in the comments section. Lets look at one question at a time

1. How was your interview letter ? Did it had detailed instructions, maps etc on how to reach the office/place of interview ? Did the letter contains process of interview, approximate time it takes ? Does it say anything about transportation if the office is out of main city area ?

Most of the interview letters, just contain address and no map or instructions. Now this can be just inertia Or it can be because the Organization doesn't care enough to make it easier for you. But even the inertia is a symptom of Organizations culture. If the letter does not contain process of interview, approximate time it takes, what time you should reach there then the chances the Organization doesn't care enough about your time. Corollary is that probably it won't care about your time either after you join. So be prepared to overwork.

2. How the Security guard treated you ? - Like a Person or a transaction.

These observations tell you about the culture of the company. Personally, I like to be treated as person and not a transaction. Did Security Guard treat you a decent person or treated you as potential thief ? If the Security Guard treats you as potential thief, probably the company (and company policies) treat the employees in the same way.

3. How the Receptionist treated you ? - Like a Person or a transaction.
Again I like to work in a company where I am treated as individual and as a faceless/identity less entity.

4. How was the atmosphere in lobby ? (e.g. Like a dentists office, Alive, throbbing, uninterested)
I will like to work in alive, throbbing atmosphere. Are there any other company employees around ? what were they discussing ? Was the discussion animated or was it just a small talk ? It gives you an idea about the interests and enthusiasm of the people you will be working with. If you are spending 8-10 hrs with these people, make sure that you will like working with them.

5. Are there any books, magazines, news papers available in lobby ? Are there any technical magazines available ?
Again was the magazine available were old-old tattered issues like a waiting room , just news papers, or some recent issues of technical magazine. Did the magazines more like just business or more technical ? All these are small clues about what the company considers as important.

I will my thoughts about remaining questions in subsequent blog entries.

Wednesday, July 28, 2004

Body language of the Oraganization

The book 'Art of Innovation' has a interesting chapter on Body Language of Company. As you know verbal communication and communication from your Body Language can be different. Your posture and actions convey more about your thoughts than what you are speaking. In similar fashion, organizations also have Body Language the Verbal/Written communication from Organization may say 'employees are our most important asset' while the actions may give a totally different picture. If you are in the company for 4-5 years slowly you start missing these subtle communications. In this post, I am going to look at Body Language of the Company from the perspective of a candidate appearing for interview. Of course, I am no expert on Body Language, but these are what my interpretations will be.

Assume that you are appearing for a Interview in a Software Company. As the interviewer judges your body language and interest, you also have to judge the body language of the Organization. Ideally, the Organization should worry what its body language is saying to potential new hires. So in a way, this post is beneficial to both (hopefully).

This is what happens in a typical interview
  1. You appear at the company door, security guard checks your interview letter
  2. Security guard tells you to go to reception.
  3. At reception you again tell that you are here for interview and you are asked to sit in the lobby.
  4. The HR person arrives some time later and takes you to a room for some written tests
  5. After the written test is over, you sit in the room for some more time.
  6. HR person comes back and tells you if you are passed test or failed.
  7. If you passed the test, you again wait for some one to interview you.
  8. After the interview is over, you come out.
  9. If the interview is in another city, you find out a way to get back to station/bus stop etc.
Most of interviews are this way. Lets look how to observe the Body Language of Organization.
  1. How was your interview letter ? Did it had detailed instructions, maps etc on how to reach the office/place of interview ? Did the letter contains process of interview, approximate time it takes ? Does it say anything about transportation if the office is out of main city area ?
  2. How the Security guard treated you ? - Like a Person or a transaction.
  3. How the Receptionist treated you ? - Like a Person or a transaction.
  4. How was the atmosphere in lobby ? (e.g. Like a dentists office, Alive, throbbing, uninterested)
  5. Are there any books, magazines, news papers available in lobby ? Are there any technical magazines available ?
  6. How much time you have to wait in Lobby ?
  7. How much time you have to wait to hear the written test result ?
  8. How much time you have to wait for interview to start ?
  9. What are the questions asked in interview ? Is interviewer judging your knowledge of arcane language syntax, your memory for API names etc. ? Did they ask you to write code ?
  10. How was the furniture in waiting room ? (e.g. Fancy, comfortable, utilatarian, etc)
  11. Did company give you lunch in company canteen ?
  12. What was talk/discussion topics the during lunch on your and other tables ?
  13. Did company offer you any transportation to go back from office ?
  14. How are the cubicles ? Did you see any speakers, books, novels, soft toys, loved one photographs, in cubicles ?
  15. Did all the computers have same wallpaper and screen saver ?
  16. How much you spent in total compared to what was general time stated in interview letter ?
Each of this question is important. I will give my interpretations in next installment. Mean while feel free to add your experiences and your interpretations.

Monday, July 12, 2004

Implementing a Well behaved Singleton - 3

Last time I showed an singleton implementation where 'User has to manage the destruction of Singleton object'. (the part-2 is here). In this part, lets see how to improve on that.

class FooSingleton
{
public:
~FooSingleton(void);
static FooSingleton& GetFooObj(void);

private :
FooSingleton(void);
private :
int m_var;
};

FooSingleton&
FooSingleton::GetFooObj(void)
{
static FooSingleton fooObj;

return(fooObj);
}


If you compare the code from the Part 2 and this code, there are small difference.
1. GetFooObj function is now returning a Reference to FooSingleton and not a pointer. So chances of user, copying and deleting this pointer are less.
2. There is no global FooSingleton pointer. The GetFooObj function is now using a function static instance of FooSingleton (fooObj)


The result is
1. when fooObj is created on the first call to GetFooObj().
2. Every subsequent calls same instance is returned.
3. Since this is a static object, compiler manages the destruction of the object. User don't have to worry about destructing the singleton.
4. Singleton object creation sequence is now predictable. So if some other global/static object is dependent on existence of FooSingleton instance, GetFooObj() function will create it at appropriate time.


THIS IS GOOD. Most the problems with previous implementations are taken care off. However, the destruction sequence is still not predictable. And that is topic of next entry in the series.

Tuesday, July 06, 2004

From Ward Cunningham's interview : Simplicity in programming

Someone says, "You should always check your arguments to see if they're in range." Someone else says, "Half the statements in this program are checking arguments that are intrinsically in range." Have they made the program better or worse? No, I think they've made it worse. I'm not a fan of checking arguments. On the other hand, there ought to be a fail fast. If you make a mistake, the program ought to stop. So there is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.


Very true. Argument checks are difficult. Personally for low level utility function I prefer to use ASSERT macros to check arguments. They are there in Debug Version to track bugs faster and no performance penalty in Release version. It has happened many times that testing team reports a bug and I start the application in Debug mode. Out pops a 'assertion failure' message. Nearly Zero efforts to locate the cause of bug. In my experience time to find the location bug is usually large percentage of total bug fixing time. If I can reduce that time, then it greatly helps in reducing the total development time and improving the project code quality.

Also it has another benefit that if you wrote a module with asserts and other developer makes a mistake in using those functions, he will get assertion failure during the development/unit testing phase itself. As you know, a bug is detected and correct early, has low cost.

Tuesday, June 22, 2004

Implementing a Well behaved Singleton - 2

In the second part of this series, Lets look at a simple singleton implementation and see how these questions affect the implementation.

class FooSingleton
{
   public :
       FooSingleton(void);
       ~FooSingleton(void);

       static FooSingleton* GetFooObj(void);

   private :
      int m_var;

};


static FooSingleton g_fooSingleton;

FooSingleton*
FooSingleton::GetFooObj(void)
{
    return(&g_fooSingleton);
}
The problems with this code
(a) There is no guarantee that User of the class cannot create another instance of the class. So technically this is not a singleton.
(b) User can derive from this class. Usually not a good idea for singletons.
(c) Single instance is implemented using file static object. The sequence of static objects is decided by the compiler. Hence if other static objects depend on Singleton instance of FooSingleton, you have a problem. It may happen that g_fooSingleton is not initialzed yet.

Not a well behaved implementation.

Lets see how to improve on this. First lets make the constructor of the FooSingleton private. This will take care of (a) and (b). Problem however is then you cannot create file static 'g_fooSingleton'. It has to be implemented differently.

class FooSingleton
{
   public:
       ~FooSingleton(void);

       static FooSingleton* GetFooObj(void);

   private :
       FooSingleton(void);

   private :
      int m_var;
      static FooSingleton* m_pFoo;

};


FooSingleton* FooSingleton::m_pFoo= NULL;


FooSingleton*
FooSingleton::GetFooObj(void)
{
    if( m_pFoo == NULL)
           m_pFoo = new FooSingleton();

    return(m_pFoo);
}
First call to GetFooObj will create the Singleton instance, subsequence calls will return the same instance. There are still problems with this implementation.
1. GetFooObj is returning a pointer. What happens if user deletes this pointer by mistake ? The FooSinglton object will NOT know that the pointer is already deleted.
2. Exactly this singleton instance of FooSingleton is going to be destroyed ? Since m_pFoo is a pointer, its destructor will not get called automatically. That could be a problem.

The User (developer) has to manange the destruction of Singleton object and he needs to be really careful in using the class (.e.g don't keep copy of the pointer to FooSingleton, don't delete the pointer to FooSingleton etc). Not a well behaved implementation.

How to improve on this is part of next installment of this series :-)

Monday, June 21, 2004

Implementing a Well behaved Singleton - 1

Singleton is one of the simplest design patterns. It also the one most abused. I have seen developers replace a global variable with a signleton object and argue that since its a design pattern, its good without really looking at the intent of the pattern and the effects.

What do i mean by a Well Behaved Singleton ? A well behaved Singleton will have following characteristics.
1. Construction is trasparent to the user(at start of program or on demand).
2. If construction of the singleton depends on some other object being initialized first, then the implementation should ensure that constructor sequence is correct under any circumstances.
3. Destruction is trasparent to the user.
4. If some other object (esp. destruction of some other object) depends on Singleton, timing and sequence of destuction of Singleton should be correct in any circumstances.
5. Single instance is ensured by the implementation. It should be impossible to create a second instance. If the user tries to create a second instance, the implementation should give an error (e.g compilation error, assertion failure etc)
6. All assumptions are made explicit.

Assuming that you understand intent of pattern and want to implement a singleton, there are many ways to achieve it, depending on your needs. First Lets look at major considerations for how to implement a Singleton.

1. Do you anticipate a need to create a derived class which is also a singleton ?
2. Does the initialization of a Singleton object depend on some other object being already initialized ?
3. Does some other object (e.g. other singleton) depend of Singleton object being initialized first ?
4. Does the destruction of a Singleton object depends on existance of some other object ?
5. How Are you ensuring destruction of Singleton ?



In this series I plan to look at some ways of implementing Singleton, look at pros/cons of them and see how well behaved they are.

Thursday, June 17, 2004

Notion of Repeatable processes

From the recent discussion on PragmaticProgrammer Mailing List:

(From Mail from Andrew Hunt)

Here's a side question for ya'll on the notion of repeatable process: I want a formula of how to make a hit movie. Perfectly repeatable, with no consideration of the talent involved. Just turn the crank and rely on the process to work.


Now replace the 'hit movie' with Software Product/Project. I never seen the concept explained with such a simple and thought provocating metaphor.

Sunday, June 13, 2004

Craft Of Programming and Mentors

One thing I learned from my experiences in Software Development is 'Software Development' is not 'Computer Science'. Its not a science and its not fully an art also. Sometime back I read an article where the author called it 'Craft'. I really liked the idea. Indeed, programming is a craft and a Good Software Developer is like a Master Craftsman.

As Craftsman you learn the tricks of the trade by doing it many times, mostly under the watchful eye of Master. There are really few Craftsman so gifted that they can learn it on their own. It means early years of Software Developer are very important. Those early years define if you become a average developer, a good developer or a Great Developer. If you are working with a Master Programming Craftsman, you will learn much just by observing how he works. If the Master Programming Craftsman is also a Good Teacher and Mentor, Then You are Very Very Fortunate.

I am fortunate because my initial years were spent with Master Programmers like T.N. Umamaheshwaran, Abhay Tarnekar, Pravin Waghmare, KK George in MSDCAD, Telco. I learned a lot in 1 year at Telco. Afterwards, I learned from the books of other Masters like Brian W. Kernighan, Rob Pike, GoF, Robert Martin, Martin Fowler, Steve McConnell, Herb Sutter, James O. Coplien, and many others.

Here is a my list of Good Books from some these masters which shaped my ideas of software development.

1. C++ Gems series
2. Code Complete
3. The Practice of Programming
4. GoF Design Patterns Book
5. Advanced C++ Programming Styles and Idioms
6. Robert Martin's articles on Design Principles.

Tuesday, June 01, 2004

Trust your developers (employees) and treat them as Responsible Adults

This is the first lesson I learned when I become a Manager of a software development team. 'Treat your Developers as Responsible Adults and Trust Them'. This simple advice, gave a me big advantage namely Trust and Support of the Development Team. 

Sometimes big benefits start with a simple ideas. Let me give an example to clarify my point.

Scenerio : An Important release of your project/product is coming up and a developer comes to you and asks for a 2 day vacation (leave). What will you do ?
The most common reaction in companies/project groups is to DENY the request. Manager will ask the developer to postpone it or even go to extremes like accusing him of 'not being a team player'.

Saying 'no' is a REALLY BAD IDEA. Does your team know the importance of the release ? Do you trust the judgement of the team members ? Do you treat them as kids to be disciplined or as responsible adults ? If you are treatng them as responsible adults and if the developer knows the importance of release and still asking for vacation, then it must be that important for him. So Don't be a PHB AND say that 'YES, you can take the vacation'.

If my release is stopped because of unavailability of one developer, then actually I am a BAD MANAGER. In Software, people do change companies. So if only one guy knows some part of the project and if he leaves for some reason, I (the Manager) am in major trouble. Its my responsibility to ensure that doesnot happen. I should not pass the blame to the team.

Treating developers as 'responsible adults' has lot of side benefits. You become part of THE TEAM. Lot of times, its team versus Manager (you). Now its Team (you + developers+qa) versus the product/project/deadline/problem. Now you have much better chance of Winning.

You respect the team members for their abilities and they respect you for your abilities. The Team is much more confident to suggest unconventional and innovative solutions to problems at hand.

If I ask the team members to come on weekend (a rare ocurrance in my teams), the team comes in without any complaints. Most of the time I don't even have to ask. If they feel its neccessary work on weekend for some reason, they will come on their own.

The team depends on each other expertise, advice is freely sought and given, the team morale and hence productivity is high.

Its real WIN/WIN for everyone...

Wednesday, May 19, 2004

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).

Tuesday, May 18, 2004

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.

Monday, May 17, 2004

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.

Thursday, May 13, 2004

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.

Wednesday, May 12, 2004

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 ?

Tuesday, May 11, 2004

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