Refactoring software

If you have done professional software development for some years then you know the value of refactoring. As time moves on, more and more
features are added to the software. The team learns a lot about the domain, problem at hand, broken assumptions and design mistakes. It is
natural that the team wants to correct the software with this new found knowledge. But most of the teams never do it. Sometimes there are valid
reasons for not doing it for eg

  • The software works and meets the user need. And the software has already matured enough. There will be no more active development.
  • The software contains lot of fixes with respect to issues from the field. If a refactoring is done then all this polishing will be lost.
  • There are no unit tests available for the software. So there is no way to check the refactoring for correctness.

But there are times when a refactoring is being avoided for the wrong set of reasons like

  • The product owner wants new feature over refactoring.
  • The team is lazy and considers the complexity as a pride.
  • There are no resources available to do refactoring.
  • Team wants to do a reengineering instead of refactoring.
  • The manager believes that refactoring is a waste of time.

From my own experience all these reasons can be avoided and refactoring can be done. Let me take one by one and see how we can get around.

Product owner wants new feature over refactoring

Refactoring will not provide anything new to the user. The user still provides the same set of inputs and the software responds back
in the same manner. So if we request the product owner to allocate time only for refactoring then we will never receive the time for it.
And the alternative is to take the entire new feature request and based on priority trade the least priority items for a refactoring. This way
product owner gets the new feature and the development team gets some part of the software cleaned up.

Team is lazy and considers the complexity as a pride

Most of the software development team starts with a clear and concise design. Over the time with the advent of new features and new team members
the design accumulates lot of incidental complexity. Instead of planning some time to identify and fix this situation, some teams tend to enjoy
this complexity. Smallest of the fix takes lot of time, new developers often find themselves lost in call stacks and no one can guarantee something
will work by design. If this situation is not properly handled then in the near future the whole software will need a reengineering. An expert
will always come up with an elegant and simple solution. So teams need to get out of their comfort zone and cleanup things then and there.

No resources available for refactoring

Most of the time finding resources to do refactoring is always hard. There are different solutions to this one and I have one solution that
always worked for me. Whenever I get a new team member as a replacement for some attrition I spend some time in training them. As a part of that
training I request them to refactor some part of the software. Yes new developers are crude, they lack the knowhow, they may complicate that
part etc., And one important fact is they have lot of energy and want to prove themselves. For me the refactoring succeeded most of the times using this technique. Give a try.

Team wants to do reengineering instead of refactoring

Most of the time if the topic of refactoring is started, some teams always want to throw the whole thing into bin and start a fresh. This may look
fascinating. But old code is not bad. It is not a rusting iron. Actually old code has accumulated lot of runtime knowledge. It contains lot of
small tweaks here and there with respect to customer feedback. So if a team is matured then it will always prefer to preserve the old code and
cleanup only those parts that are ugly.

Manager believes refactoring is a waste of time

In any industry the highest paid person’s opinion (HIPPO) has lot of value. So if you really want to do refactoring the manager has to be
convinced about the advantages and benefits. Here I have seen always show the benefit as something concrete. For eg number of saved man days,
amount of money saved, code/design metrics etc., Managers tend to believe hard facts and numbers over qualitative statements. This too has worked for me in the past.

So take that extra effort and cleanup the code.


Resurrecting my sisters Samsung galaxy captivate i897

It all started simple. My sister owns a Samsung galaxy captivate i897. It is a nice phone considering its release time line. It had good specifications, fast camera, good build and light weight. She was using it mainly as a phone and as a primary camera. Like every non tech person she never bothered to add an additional sd card and kept all her beloved photos within the built in phone memory.

Problem 1 – Broken screen

First problem started when she broke the screen by dropping it. Everything was functional but nothing on the screen. All the photos and memories are locked inside this device and after all possible tries I couldn’t get the photos out (usb debugging was turned off). So I decided to change the screen myself and ventured out to buy one from the market. Since this phone is from AT&T and we currently reside in Bangalore India, I couldn’t get the replacement screen. I finally bought it from USA through one of my friend. Thanks to youtube, I changed the screen myself. I took a backup of all the photos and as an additional step installed cyanogen mod 10.2. The phone did get a fresh air and started to look more like a modern phone. Everything was fine.

Problem 2 – Failed internal sdcard

Second problem showed up after some months. The phone refused to boot up now. I thought it was because of firmware corruption and tried to reinstall it. Again the phone always booted into recovery. Then I cleared up my mind and read the error message that the system showed patiently. I understood the internal sdcard has failed. Again I tried a lot and finally gave the mobile to service center. They mentioned it is a hardware failure and they won’t service it. I took that to the local cellphone repair service. They too mentioned that the phone cannot work without the internal sd card.
Now being an engineer one always try to solve a problem when everyone else says it’s impossible. After some thought I felt if I can switch the external sdcard and the internal sdcard at the software level then the system should be able to boot using the external sdcard. Now I am just going to list the solution and not the full story

  • The external sdcard should have the same partitions like the internal one or else the system refused to use it. So I partitioned the external sdcard into 2 partitions. 2gb & 6gb each of type vfat.
  • The custom firmware didn’t pick up this card as a replacement for the internal sdcard. But the stock firmware picked up this card for its /data partition and the phone booted up.

Problem 3 – The phone doesn’t have a sdcard

The phone was functional but if one tried to open any of the application that needs to store data, it would close with an error there is no sdcard. I checked the settings>storage and found the 2gb partition has been mounted but the 6gb partition was not. I again started a search and from my little linux background I know that the mounting can be changed by modifying the fstab file. But the fstab structure has changed a lot in the recent times and also I should have root privileges to change it. Again I am going to list down the solutions here and not the full story

  • I used to superoneclickroot from the xda forum and rooted the phone.
  • I used adb and downloaded the /etc/vold.fstab file.
  • I modified the mount point of the sdcard to the external sdcard partition.

Voila the phone works and also the sdcard was scanned during the bootup. I gave the phone back to my sister. The moral of the story is “If you build a system from open technologies then there are people with time and effort to fix the problem on their own”.

Pages that helped me
Get SuperOneClick from here
How the Mount SD Card Android Process works

Working with Germans

I am working for software wing of Siemens, Bangalore for the past 8 years. During this time frame I have travelled 4 times to Germany and have worked in Germany for a year. As a part of the work I have to interact with my counterparts in Germany regularly.

As a regular practice I under went the intercultural training regarding Germany. It was a big eye opener and I learned couple of things while working day to day with the German counterparts.  I will share them here. Since I am an Indian, the points may also reflect to some extent what Indians observe.


The German communication is mostly straight forward. If something is right they say it as right. If something is wrong they say its wrong. If there is a bad news they say it on the face. For eg if a German is not happy with you for some reason then he would say it directly on the face “I am not happy with the way you are doing this”. Also I have seen that they expect similar kind of communication back. And if someone does the round about communication beating about the bush they get annoyed. Being black and white is always appreciated.

Value of Time

The Germans are known for their punctuality. One thing that I have learned is they value other’s time a lot. If a German arrives late for a meeting the first thing he does is apologize. The next part of it is Germans value their own time a lot. For example if a German wants to work on a particular topic with full focus (undisturbed) he will block his own calendar and mark it as busy. And if the calendar says the time is free then really the German is available. One can send a meeting request. They balance the time needed for personal & professional activities well.


The German people are mostly inexpressive. This is what the trainer said during the intercultural training. This description is given because most of the time the Germans look too serious and focused. In the office this is a routine one can note. Every morning once a German enters the office he will greet with “Morgan” meaning “Morning” and then starts his work. There is no gossiping, chitchat and in the evening “Tchuss” meaning “Bye”. When I was working in Germany I normally used to hear songs during work (with my earphones on) and sometimes I used to hum the song. Once a colleague of mine complained that it disturbed his attention.

But this description of Germans is not true always. I have seen them angry, depressed, happy, humorous & satirical lot many times. What matters is majority of the time they look serious.

Long term Planning

Germans are known for their meticulous long term planning. This is quite evident from the kind of projects they execute successfully across the globe. They are masters of long long (10+ years) planning. I have seen lot of initiatives when they reached me were planned, started & executed lot many years earlier. They don’t bother about immediate results. They really value long time benefits. That is the reason they plan, start, execute and reap the benefits in the end.


The one attribute that I envy most is their ability and commitment towards documenting things. The documentation is not done just for the sake of process. It is done so that tomorrow it helps someone out when the author has moved on. And this shows when a German reads the document. He will read it with full attention (not skimming through) and trust the information. Also whenever some information is required Germans always look for a written document rather than running around people and pestering them.

Individual & Contradiction & Conflict

This is another attribute which I learned by experience. Majority of the Germans like to be individualistic than be part of a group. For example in a meeting when all the participants agree and one German disagree at the end of the meeting, everyone accepts that one among them disagreed. No one forces him to agree to the group. The individual who is disagreeing also never agrees due to peer pressure. Each one of them express ones own opinion.


At times I have felt that Germans are slow. Because they approach  everything very systematically. Don’t skip unwanted things. They don’t take shortcuts. They also don’t bother to rush through things. This all activities will definitely slow down things. But the outcome in the end is always fruitful.

This is a topic where people write books. A blog post is too short a space for such topic. But I just collected the most important ones that I could get.

Performance Evaluation

This year I am designated as an architect. And I am not responsible to do performance review for the team members. But in the past when I was a manager this used to be a long, tedious and time consuming job(I had 9 team members that time). So I thought this year may be just look back at the last couple of performance reviews. If some of my old team members are reading this blog then they may know which instance I am talking about but the point here is to look at the process as a whole how it happened in the past.

Preparation Phase

As a manager I have to remember all the work done in the past by each team member and also the various key events that happened. If I go unprepared then already it will look like I am not concerned about the team member. Also doing a fair review without preparation is not possible. So here is the list of item that I prepare before going to the meeting

  • The tasks allocated to each team member and how he performed it.
  • Specific instances where the team member helped other team member and the team.
  • Specific instances where the team member had created trouble for the team.
  • The major plus points of the team member.
  • The major minus points of the team member.
  • What is my expectation? What I look forward?
  • How the team member has performed with respect to previous years expectations?
  • If the team member joined in between then take the feedback from the previous manager.


Then comes the real dialogue with the team member. Utmost I used to take 2 team members per day. I find a nice spacious room with good lighting for the dialogue. And before getting into the room I say to myself allow the team member to speak more and allow him to express his point of view. The following are some of the challenges that I faced in the past

Team member comes unprepared for the dialogue

This is the funniest one when I go prepared the team member comes without any preparation and just tries to think over during the dialogue. Or some times the team member will post questions to me regarding what he did all the time? In most of such scenarios my prepared task list helped me a lot. But I have always felt such dialogues are not that constructive. Mostly the team member attends the dialogue with “nothing is going to change” attitude.

Team member comes with lot of paint points

The team member makes a huge list of all the paint points and wants to discuss only those issue. Here the problem is the team member never wants to listen anything that is good that happened to the team member during that time period. The dialogue then becomes each one defending themselves.

Team member do not know what he/she wants

The team member comes to the meeting and says that one is not satisfied with everything. But if asked “what one wants?” then I get a blank face. One of the team member even told me that in a performance review if someone agrees that “one is satisfied with the current state” then such team member will not be compensated well.

Team member assumes lot of things that is not known to him/her

Most of the time when a decision is made regarding a particular person that person is not part of that meeting. Because of this most of the team members will assume and create lot of story/rumors that are baseless. Talking to such team members in a performance review is always hard because even if I knew the truth I cannot expose that in front of that person because I may leak some information that is not meant for him/her. And even if I expose the truth still the team member liked to believe the baseless assumptions because that gives a feeling that the team member is a victim and is suffering.

Team member compares with other team members

The dialogue becomes very complicated once the team member starts to compare himself/herself to another team member. I personally hate doing the comparison and try to avoid such discussions. But there are some team members who wants to compare with others and prove that he/she is better than that compared team member & being paid less. Most of the times in such situations I try to convince the team member that this comparison is not going to take us forward in any way and stop it.

Discussion related to pay packages

The discussion related to pay package and remuneration is the hardest one. The team member brings in lot of assumption but the hard fact may be different. As a manager I cannot reveal this information. But I do the discussion entirely using a imaginary pair of team members and just discuss the issue. By this I avoid comparing 2 real team members. For example if a team member says

“I get lesser salary than person X”

I do the discussion something like this

“Let us assume a person A joined during the year 2005 and person B joined the during 2009, Person A may be getting salary less than B but A gets a yearly retention bonus which is not given to person B”.

It is not possible to avoid this topic in performance review meeting. If I avoid, then the team member feels that I am not concerned regarding the team members growth. In performance review “Money is not the only factor but money is one among the important factor”.

Manager: On becoming a software architect

After spending past couple of years managing a small team of 8, this year I switched over to software architect’s role. I have completed my first 6 months as architect now. I am sharing my experience how the journey is as of now. The following are some of the key things that I noted


The first and foremost question that came to me was “what should I do now?” Should I continue to do the same thing what I am doing or do something different as an architect. The role of an architect was not clear to me and because of that I am not sure where do I stand as an architect.


The architects role is mostly given to a senior developer who has proven his design capability in a couple of the modules. I too come with a similar background (imaging and 3d being my area of specialization). But moment I was made an architect the entire team of 30 developers expect me to know the solution to all the development problems. Sometimes when I say I don’t know the direct solution and ask the developer to look into a particular area for solution they look puzzled and feel bad.

No Team

The next major area of discomfort is due to my managerial background. Suddenly I don’t have a direct set of team members to report under me. This has created some kind of void for me. But I have lot of time and feel lot lighter because of this. But I miss the task allocation, tracking and pressure to deliver on time.


As an architect I need to make lot of decisions within a short span of time. Developers come with a problem and a couple of solutions. Now it is up to me to choose one among them. I am slowly learning to make informed decisions faster. The thing I lack is to remember the decisions that I took sometime in the past. I need to find a way to document the decisions or else when I go back with a concern regarding particular implementation the developer responds back that ”you asked me to do so”.


There is a bunch of architecture trainings for which I have been nominated. Each of the training starts with the objective of defining what a software architect should do and details a list of established process and methodologies for that. After attending all those trainings I understood that now I need to communicate with more stakeholders and take ownership.


As an architect the communication does not stop at the architecture specification document. Because normally the entire development team do not adhere to those guidelines just like that. I need to make substantial effort in communicating each architectural aspect to the teams clearly and concisely. Sometimes white board and a closed room is far better than a power point presentation or a word document. Even after so much communication I need to accept that there will be deviations that I need to live with.


The one thing that brings lot of sense and satisfaction is majority of the team members show lot of respect.


Attributes of a good team

I wanted to know why some team always achieve their targets in style and still enjoy every day “what are the attributes of a good team?”. After leading & watching couple of different teams in the past 6 years in my opinion the following are attributes of a good team in my opinion.

Conflict within team

All team have internal conflict. Because all team members are not same. But a good team uses conflict to its advantage. No one just agrees to the decisions without a debate or question. If some thing is wrong it is communicated on the face. The same members who debate fiercely inside a meeting are the ones who sit together for a happy chat in the coffee table. The outcome of the conflict is always positive.

Mutual Respect

All the team members have mutual respect for one another in a good team. It makes the team more integrated. It makes the team member to listen to others point of view. It also provides courage to others to express their point of view. It makes the team to commit itself to a decision made. It brings in self discipline and a sense of satisfaction. It also makes the senior team members learn from their own juniors without any ego. It makes communication open within the team.


All the team members put themselves into the other person’s shoes before asking the other to do something. This way each team member knows what is the feeling from the other team member. A good team never brands a particular team member to do particular kind of job. Each team member yields and shares the good work with others. Also all the team members take up painful jobs too. It increases sharing within the team.

Share success & failure

All the team members shares and celebrates the success together. A single team member do not hijack the team’s success. Again when there is a failure the whole team takes the responsibility together. A single person is never made a scapegoat. This builds up trust within the team. The team members learn to take up success and failure the same way. People don’t take the success to their head and failure to their heart.

Share knowledge

All the team members irrespective of experience shares the knowledge with other team members. The collective knowledge of the team grows exponentially over a period of time. New team members are productive in a short span of time. All team members feel that knowledge is to be shared and doesn’t hold back essential knowledge with them. Since knowledge is power the team achieves more in less time when compared to other teams.


Each and every team member display leadership quality (I am planning a separate post for this). All the team members own and take responsibility for the team’s output and delivery. Individual team members put team’s priority ahead of their own individual priorities. They help the manager in making informed decisions. Problems are communicated well ahead.

Help one another

All the team members help and support one another. A team member falling sick, someone in the team needs an unforeseen leave, Someone injured etc., are taken care by the team. All the team members gives priority to the missing team member’s task. This way the loss of the team member is only visible to the team and outside the team nobody feels the loss. During these situations all the team members stretch whole heartedly. This builds trust and the missing member recovers faster due to lesser stress.

Responds stronger during crisis

Every team goes through a period of crisis and tough time some time in the life span. This is the best time to identify a good team. A good team remains cool whatever may be the situation. It collects the list of problems, time available & resource available. Then the team works out a solution and implements the solution with utmost focus. The team comes out of the crisis successfully. During this whole time no team member criticize the other team member. The team is always focused on the task to be done. From the outside no one can feel that the team is in crisis.

Learn from the failure

Success and failures are two sides of a coin. A good team responds to failure with a positive attitude. First the team searches for the root cause and not for an individual. Once the root cause is found, the team seeks how to avoid that in future. Then the team forgets the failure and remembers only the lesson taught by the failure. In future the team doesn’t commit the same mistake again.

Finds solutions

For a team it is very easy to find problems, escalate, crib and wait for someone to solve. A good team does the other way. It searches for solutions. It never waits from some one else to come and fix their problems. All the team members actively participate in the implementation of a solution. All these small solutions act as a lubricant that reduces the friction in the day to day work. Mostly the team members are happy because no one is worrying about problems but all are actively searching for a solution.

To conclude the following saying perfectly applies to teams also. Its people who make a team.

“Great people talk about ideas.
Average people talk about things.
Small people talk about other people.”

– Ferose

Hello world!

Welcome to Yes I decided to use wordpress instead of blogger. Somehow I was not comfortable with the blogger interface or may be the theme. I moved all my old posts from various blogs here. Let me see how much I can during this year..