There is only one reality. That is Code. Everything Else is Illusion

There is only one reality. That is Code. Everything else (design and documentation etc.) is illusion.

Once I worked in a team, where the managers expected detailed design for everything. When, I say, we will have a single library for validation and data storage etc., they won't accept it. They expect the application to be modularized, and have many components. If somebody proposes multiple libraries, with each library doing one small work, they would be very happy about it.

I am very bad at presenting these things, and coming up with big architecture for very small problems. There was a person in my team, who is very good in these things. He came up with a design, in which, there are multiple libraries. One library for business logic and one for data storage etc.

There will be one business logic library, which does all the validations and processing of the data and the conversions from UI to DB and vice versa. The DB layer handles all the save and retrieval of data, and it is not burdened with any processing of the data or business logic. The entire business logic would be in the business logic library. In future, if the business logic grows, we can split into multiple libraries based on the functionality. Since, it is the first version, we can start with one library and see in the next release whether to split this library.

At the end, most of the methods in the business logic library are like this.

public BIObject GetBIObject(Parameters)
{
    return dbHandler.GetBIObject(Parameters)
}

public BIObject SaveBIObject(Parameters)
{
    return dbHandler.SaveBIObject(Parameters)
}

[For those who did not understand the above, the entire functionality (validation, storage and everything else) was developed in the data library. The business logic is just a wrapper with one line of code for each method.]

Everybody was happy by this method.

The managers were happy, because, the design is good, where there are multiple components, and it is modularized. The other developer was happy, because, the managers were impressed with his design. I was happy, because, the code was exactly the way, I wanted it to be. And, also, I was relieved from the burden of designing (which I never used anyway) and presenting it to the managers.


Related Links:
What does it take to convince a Manager?
Developing Libraries - Give Minimum Privileges

Taking Employer's Product Unofficially and Selling Outside

Long back, When I was working in a product based company, which sells products to big organizations mainly in US, I had discussion with my colleague on taking Company's products unofficially and selling outside.

My colleague started talking in such a way that, you cannot take any code outside. I told him that, everything is open here. You can take the code out in so many ways. But, the company trusts us. That's why, they had given full access to everything.

Then, he said something like below,

They don't need to have trust. If you can take our product and sell it to anyone yourself, then our company will appreciate it, and will make you as the official sales partner. They will give you good percentage in the sales by taking all the headache of new feature development, support, maintenance, bug fixing, legal and many other things.

Discouraging MBA

Whenever anyone says that, he/she is planning to do MBA, the first thing that I do is, to discourage them in all the possible ways. Depending on their interest in terms of higher education/money/management, I suggest M.S./M.Tech, or to join a startup, or to start their own company etc. As much as possible, I try to prove that, they are going to waste two years of their time by doing MBA. But, once, I failed miserably.

She does not like software and wants huge salary.

Leaves and Leaders

I have heard of few leads/managers who do not accept the leaves of their team so easily, even if they are given sufficient advanced notice.

One reason for this is, the team member is indispensable, and if he/she leaves, the project cannot proceed till he/she comes back. The lead cannot lead till then. So, they reject the leaves. If the team member has to go at any cost, then they may leave, even if the leave is not approved. In those cases, few leads escalate these issues to higher management.

I did not understand for a long time, why these leads unnecessarily escalate these issues to higher management. The time won't come back. Even if they escalate, next time, when the team member has to go on leave in emergency, they won't stop. The lead would be just spoiling the relationship with the employee. Instead, if the lead praises the team member how important he/she is to the team, and how indispensable he/she is, then the team member would get more enthusiasm, and would try to do something, so that, the project won't fail.

Later, I realized that, these things are used by leads/managers to pass the blame on to the team member. If the project fails, then the lead or manager immediately say that, since this team member went on leave without approval, the project failed. The lead says, he/she cannot deliver the project, when he/she does not know when the team members leave without any notice.

In many service based companies, the team members shuffle frequently. So, even if the relationship is broken, the lead/manager do not care about it.

Of course, if these "so called" leaders get opportunity to work with people like me, everything would be set straight. ;)

If the leader is not ready to take 100% responsibility for the failure, then he/she is not worth of being called as a leader.

Over Qualified, Under Employment and Bad Work Do Not Exist

Many years back, at the beginning of my career, I was talking to my colleague, New Melchizedec. He told me that, for him, Salary matters more than the kind of work. I asked him, whether he would do a job which can be done even by a 10th class student. He said, he would definitely do it, but, not like a 10th class student, but like a computer science graduate.

It took me many years to understand what he meant. After understanding it, now, if anyone does not follow this, I won't be happy in taking that person to my team.

Many employees ask their company to provide good work. But, the company hired them to solve it's problems and not to provide good work. It is completely upto the employees to solve the problems either with good work or bad work.

Once, an acquaintance of mine called me for some small help. He wanted to download many files from a website. At that time, he could not find anyone else to do this bad work. So, he called me. He told me this, and went out and returned after few mins. Then, he told me that, he would start downloading the files from the bottom, and asked me to start downloading the files from the top. I told him, I had already written a script, and the files are getting downloaded. And we just did gossip till the download was over. He was very happy for that, because, last time, he and three more people had to spend few hours in downloading it. Now, I did not spend more than few mins.

If he gets another bad work, and if he has opportunity to call either a highly qualified person or less qualified person, I am sure, he would directly call the highly qualified person to do that bad work. The expectation is, the work would be done in very efficient way. If the highly qualified person thinks that, he is under utilized, nobody can help him.

The employer wants the problem to be solved. The employer may also give some method of solving the problem. It is upto the employee, whether to use that method or any random method to solve the problem and criticizing the employer for not giving good work, or using the most efficient method, and let others call that as good work.

Another example

I have seen an application, which is developed in a technology in which I cannot write anything other than "Hello World" program. That has just five pages with some data storage. In general, highly qualified people are not interested in doing the application with just five pages. So, it was given to a normal developer. After developing that application, the developer moved out, and I was given the control of the server which hosts that application to maintain it. That's when, the real problems started.

The application is developed in such a way that, it cannot be taken out and host it on a different server. They hard coded and assumed the OS, Path on the disk, path in the URL and everything else. The only way for me to deploy a new version of that, without touching any code is, buying a new server and installing the same OS and deploying in that. Nobody would sponsor a new server, just to deploy such a small application.

So, there is no backup. So, if there is any issue, I have to directly work on the production server and fix it. Since, it is production server, I cannot debug so easily. Since, it is production server, I cannot give control to others. So, I cannot take help from others, unless they are going to sit next to me and help me in that. There are so many issues like this.

If the same work is given to a highly qualified person, and that person develops the same application like how a highly qualified person develops rather than a less qualified person, then I would not have faced so many problems in maintaining it.

Many highly qualified people forget that, when they are given work of less complexity, the work is supposed to be done the way highly qualified people do rather than the way less qualified people do. Everybody should do the work in such a way that, no less qualified person can get the same quality. Otherwise, there is no use of hiring that person. We can hire a less qualified person with lesser pay.

I feel, the most under employed job is, taking care of children.

Not Giving Control in the Name of Improving Efficiency

The following is the notice that is sent to all the heads of the business units in a company.

We are changing the process of purchasing the hardware in our company. Till now, all the business unit heads are buying the hardware for the needs of their business units. Going forward, the entire hardware would be bought by the IT department. Business Units Heads will have to raise a request through IT department. IT department analyzes the request, and buys the most efficient hardware which satisfies the business requirements and reduces the cost for us. This is to improve our efficiency and reduce the costs.

Director of one business unit wants to buy a powerful server which costs around $100,000. He has a budget of $10,000,000 to run his business operations. According to the new rule, the hardware purchase has to be approved by the IT department. For that purpose, he meets the Director of the IT department.

Director of Business Unit: I would like to purchase one powerful server that costs around $100,000 for processing of some huge data.

IT Head: Why do you need that much powerful server? Why cannot you use normal computer for the same? If you need more CPU power, then use multiple computers.

DIR: We get huge data every month, and we would like to get the analysis results as soon as possible to take better decisions sooner. The application that we have does not support parallelizing. So, we need powerful server.

IT: Then, ask the application vendor to add support for parallelization.

DIR: They may ask $500,000 to support parallelization.

IT: That is your assumption. It should not be that expensive. If they write code in a clean way, then it should be straightforward to support parallelization. Raise a Request for Proposal (RFP) and ask them, how much they are going to quote for this. Or just do it yourself.

DIR: They write very clean code. That is not the issue. Since, they are product based, their cost is very high, and we are not allowed to change their code. If we raise RFP, that also would cost us minimum $25,000.

IT: Nobody asks money for RFP.

DIR: They don't ask money explicitly. But, they would add this expense in other items that we buy from them. Even if we get the parallelizing capacity, we will have to spend more time on our side to make sure that, the application is running in all the services, and restart it, if there is any failure. It requires me to allocate few people explicitly for this.

IT: Then, automate it. You don't need to go to that expensive company for automation. There are many other companies out there, which can automate these for very less cost.

DIR: Can you take care of the automation?

IT: No. We are too busy. We don't have enough bandwidth to do those. You will easily find plenty of companies which can do it for very less cost.

DIR: One of my team members assured me that, if I provide him this hardware and one day per month, he would provide me all the data that I need, in the least amount of time, without asking me anything else. If I have to go by your approach, then myself and my team members will have to spend lot of time in getting these things done.

IT: Initially yes. But, we would be saving lot of time in the long run.

Later, that director gave a contract to the original vendor, which developed the application. By that contract, the vendor would run the data analysis and give the analyzed results to this company. For this, the vendor would get $100,000 per quarter.

Inspired by a real story. There are many companies, which are surviving only because of these policies in big companies.

Quote of the Day - Decision Power to Multiple People

The most easiest way to destroy a company/project is, instead of giving decision power and responsibility to a single person, ask them to take decisions by consensus and have collective responsibility.

I did not do anything

I did not do anything. But, it is working/done.

There are few people who say like this regularly. Many managers feel like, "They spent 5 days to write 10 lines of code." or "They just reused the code. That's why, it took less time".

The efficient solution always take some significant time. When it is implemented, it looks like, it should have been done in 5 mins and not in 5 days.

In most of the good implementations, the time one spends for design/study/discussions/thinking etc., is much more than the time they spend for coding. Thinking of an efficient solution for 2 days and implementing it in 2 hours is common for very good developers.

Reusing is not as simple as one thinks. It would take some significant effort to understand the existing system, and how it can be used for our needs. That study takes more time. Once that is done, it looks like the developer has not done anything, whereas it was not the case.

I am always happy to work with people, who regularly say, "I have not done anything. But, it is working". Whenever say this, I understand it as, they are providing the efficient solution.

Different Roles in Software Development

In many product based companies, the developers at different levels starting from Trainee Software Engineer till Distinguished Engineer, are given the same kind of work. But, the way they do that work would be lot different.

If some work is given to developers of different levels, and if all of them do their best, then others may say the following in response to their work.

Distinguished Engineer - He has not delivered anything.

Principal Software Architect - He has not written even single line of code.

Technical Architect - Even a kid can write the code that he has written.

Sr.Software Engineer - He has developed a complex functionality single handedly.

Software Engineer - He has developed one of the most complex functionalities with very good design, which uses all the concepts of design patterns.

Trainee Software Engineer - He has developed the application by using all the latest technologies, it's latest features, and all the concepts of design patterns. To understand what he has written, one needs to learn all the latest concepts in the latest technologies.


(If the problem can be solved by changing the process or the way they use the system, then it won't require any new product to solve the problem. Even if it cannot be solved by changing the process, if it can be solved by using existing products in a different way, that would be better. That's how, Distinguished Engineers and Principal Software Architects work.)

By the way, My lead is taking lot of time to understand the code that I have written with the latest concepts. I also used the following comment, while sending for review.
// When I wrote this, only God and I understood what I was doing
// Now, God only knows

When do we get time to clean our code mess?

When do we get time to clean our code base?

This was the question asked by one of my colleagues to the Executive Vice President in the all hands meeting.

The Executive VP heard it like code mess (and another VP corrected it). He said something like, come up with a plan with the manager and the director, and he would consider that etc.

The following are my thoughts on the same.


Before asking the time for cleaning up the code base, I have few questions.

Did you write clean code yesterday?
Are you writing clean code today?
Will you be writing clean code tomorrow?

If the answer is No, then there is no point in asking extra time to clean up the code base. If we are not going to write clean code in our every day tasks, and asking separate time to clean the code base, there is absolutely no use, and it is just waste of the time, resources and money. First we should concentrate on writing clean code everyday, and then we should think of cleaning the existing code.

In any business, it is of no use to spend some extra time to clean some code base, unless we are 100% sure that, the code need to be changed soon with short dead lines, and also before that, we will not get any feature which requires re-writing of that. If the code is going to be re-written soon, then there is use of cleaning it now. We can directly re-write it later on. Whenever we get the change request in a component, at that time, we can try to fix the design/code of that component. Only, if we are sure that, the time that is given to those change requests is not enough with the existing design, we should fix the design now. Otherwise, there may be no use of cleaning it now.

If we are modifying a component, then the modified design should be in such a way that, all the parts that you are touching and it's integration with other parts would become very clean after that. If you are writing code, not only the exact parts that you are touching, but, all surrounding parts of the code also should be cleaned.

If you are changing a method as part of a bug fix, then may be you should look at the entire method and it's usage, and see whether you can rewrite the method in a very efficient way. If you are adding a method in a class, may be, you should look at redesigning of few methods, so that, the class would become clean.

Whenever any developer changes any code, if they look at the high level picture, and modify the code/design accordingly rather than just implementing that feature alone without bothering anything else, then within couple of months/years (depending on the size of the project), the entire code base becomes very clean.

Generally, no business person would give dedicated time to clean the code, unless, they are 100% sure that, the code would be maintained a lot and will not be re-written. They may also give time, if they have deep pockets. If they have deep pockets, probably, you can ask for salary raise first.

Courtesy: Shawn Smith (Who has shown me the difference between fixing a bug by a developer and a Distinguished Engineer. If he fixes a bug, then only another distinguished engineer can fix in such a clean way).

Showing Off Without Showing Off

Do little bit of extra work everyday, which your manager did not ask for. Don't tell him/her that, you have done these things extra which he/she did not ask for. Later on, make them realize in an indirect way that, you have done lot of work, but your manager does not know about it, because, you never cared about the recognition, but cared about only the project and company. The recognition that you get would be much more than what you would have got by giving regular updates on everything that you have been doing [Provided that the manager is little good manager].

You left for the day from office and your manager called you saying, there is an urgent issue. Ask him the details of the issue, and tell him/her that, you would be in office in 5 mins. You know very well that, it would take minimum 15-20 mins. When you reach the office after 20 mins, don't appear to the manager, and directly start working on the issue. Once you reach a state, where you have some details and need your manager's decision on taking the next step, go to your manager, and give the update. Your manager assumes that you had come to office in 5 mins.

Your manager has asked you to do something of low priority, whenever you are free. With the work load that you have, it can be done in 2 days time. But, you are lazy and do not want to do it, but, have done only after 5 days. If the work is of something for which, the manager does not need to take any action after your completion, then don't inform him/her that the work is finished. Whenever he/she asks about the update of that task, tell him/her that, it is done long back. Your manager assumes that it is done in 2 days.

I have to accept that, I am doing these things shamelessly (few knowingly and few unknowingly).

Two Developers of Same Caliber Think Alike

If there are two developers who have same caliber, and if you don't like one developer (on technical aspects), and if you are not a developer, then don't criticize him/her at another developer who has the same caliber. Because, they think alike, and if you criticize one developer at another, then they will understand that it is your mistake, and not that of the other developer.

Many years back, in the company that I was working, a new project was started, and I joined that project with another developer who has almost equal knowledge as of me. Almost since the beginning, myself and the other developer had serious issues with two non-developers in that project. They used to give so many (stupid) suggestions on many design/architecture aspects, which we have thrown into garbage, and they were very unhappy with that. We used to rebel with everything that they used to say. We never interfered into their work, but, when they were trying to interfere in our work, we used to reject everything. They felt like, because of not using their suggestions, the project was going slowly. After few months, they had taken another developer who has more knowledge than me. Before he joined the team, these two non-developers had personal interaction with him. They criticized me and the other developer, and told him that, since, we did not take their ideas, the project was going slowly. They asked him to take the project in the proper direction by controlling me and the other developer.

After he joined the project, within few days, our work got reduced significantly. Previously, whenever the non-developers say anything, we used to spend lot of time in fighting with them. After he joined the project, he used to take the lead, and used to fight with the non-developers for everything. Myself and the other developer never needed to do any fighting and we were peaceful.

The non-developers thought by bringing that person, they would get the control of the project, but, it fired back on them. They never understood that, if one developer of some knowledge sees few issues in the design, then most probably, another developer of the same caliber would see almost the same issues in that design. Instead of trying to understand the problems in the others domain, if one gives suggestions and criticizes them, it would just fire back on them only.

Performance Review - Carrot tied to Donkey

A farmer wants the donkey to take the load and travel. But, the donkey does not move. So, he ties a carrot to the donkey similar to the above. The donkey wants to eat the carrot and moves forward. At the same time, the carrot also moves by the same distance. The donkey cannot eat the carrot, till the farmer reaches his destination.

Whenever anybody says, they are doing something because, otherwise, their performance review would be effected, I remember the above. I have seen many people who are sacrificing themselves, so that, they can get better rating in the performance review.

• They work a lot on weekends and late nights, eventhough, they are not interested in doing that.
  
  
• Sometimes, the manager asks for something which may impact the project negatively. To do not effect the performance review, they agree to the manager, which causes loss to the company.
  
  
• If one does not take enough rest, or force oneself to work more, then the productivity would go down. The correct thing is improving the productivity and not increasing the no.of working hours. Unfortunately, many managers do not follow that.
  
  
• They fear that, they may not get another job. If that is the case, then first they should concentrate on acquiring more skills so that, they can get another job, rather than just blindly following the manager. If they don't acquire more skills, then it may have more negative impact in the long run.
  
  
• Not everyone can get promotion. Most of the companies won't give promotion to more than 20% of the people per year. In that case, for everyone to get promotion, it would take minimum 5 years.
  
  
• In case of relative ranking, many people try to push down others, or would try to prove that, others are wrong. This creates a bad environment among the colleagues, if everyone is trying to get better rating in the performance review.
  
  
• If one wants more salary, the best thing is, change the company every 3 years. If one tries to satisfy the manager to get better performance rating, then that does not do any good for oneself or the company.
  
  
• If you think even 3 years is long time to stay in the company without listening to the manager for everything, then prolong as much as possible. Increase the estimates, let them think that you are less productive, and keep enough liquidity to survive for 3-4 months. Don't resign just because, the review is little bad. Resign after 3 years, or if there is no point in continuing in the same company.
  

Work for yourself and Work for the company. Do not work for anybody or anything else.

Who is to be Blamed for Bad Code?

There is very bad code in the project. The developer was asked for explanation on writing bad code.

The Developer blames the Development Manager for giving less time to finish the project.

The Development Manager blames the Program Manager for giving too many requirements without giving enough time.

The Program Manager blames the Director that, he forced to fulfill all the requirements of the client within the time frame set by the client.

The Director says, he was ready to provide more resources to the Development Manager, but, the Development Manager rejected it saying, "Nine women cannot produce a baby in one month", and he could not increase the time because of the constraints from the Vice President.

The Vice President says, he does not have an option, because, he has pressure from the CEO to become market leader in couple of months.

The CEO says, "What is the issue with the code? It is solving our problems".

Starting With the Problem or Technology?

Few years back, I attended a project meeting where there was a discussion about the new technology that we were using for the project. The senior developer proposed that, there is one concept in that new technology which is a good feature, and we should use that. Immediately, the manager said, "No. No. No. We cannot use all those. We don't have enough time for all those things. We will just deliver the basic things for this release, and we will see those for the next release." After that both the manager and the senior developer aborted that concept in that technology.

After few days, I used the same concept in the same release. Neither the manager nor the senior developer knew it. (Because, I did not tell, and there was no need to tell.)

For the functionality that I was working on, I felt that, using that concept was more efficient, and I used it. If that concept was not efficient for my functionality, I would not have used it. You should use a concept/technology, if that solves your problem efficiently, and you should not use it, if it does not solve. The statements, "We will use this technology" and "We will not use this technology" in isolation does not make any sense.

Whenever you want to do anything, you have to start with the problem and find the best approach rather than, starting with a technology and aligning that to solve your problem. This may look funny, but, unfortunately, I have seen many people who start with the technology rather than with the problem.

By the way, I still use 40 years old VI editor, and I am very happy with that.

We are closing one business to focus on our Mission

The standard dialogues from the top management who are closing a business are

• We are closing one business to focus on our mission.
• Our strategy has been changed, and we no longer want to be in this business.
• The business is no longer aligned with our vision of the company.

Would any entrepreneur close a business, if they are getting profits? If there are profits in the business (even if they are very tiny), then anyone would try to sell the business, rather than closing it.

If they are not getting profits, and closing the business, cannot they tell the same thing directly rather than telling all the management words like Focus, Strategy, Mission etc.?

Mindless Background Verification

My classmate worked for a company for 2 years and then she went for higher studies. After her higher studies, she joined back the same company and has been working for the last 7 years. After having experience of 9 years in that company, now, that company wanted to verify her background.

She gave her classmate's phone number with whom she studied for 1.5 years in her post graduation 7 years back. That company called her classmate and talked for 10 minutes about her and happily closed the background verification.

I cannot find more funny thing than this. If a person has been working for a company for 9 years, still do they need background verification? Working for a company for 9 years is pretty long in the software industry. If a person works for a company for 9 years, then after the employee's family and immediate relatives, the company is the one which would be knowing more about the employee than anybody else. Still, why do they need references of people who know much less about the employee than the company? Do they think that, those who worked with the employee briefly 7 years back can provide better information than the company in which she has been working for the last 7 years?

I cannot understand who comes up with this kind of great policies in the corporate world.

Formula For Job Safety

	a * {Effort spent for the Company}
Job Safety =		+	b * {Effort spent for the Manager} * (log({No.of Employees}) - c)
	log({No.of Employees + 1})

Where a, b, and c are constants.

For those who are not very good at formulas,

If you want high job safety, If the no.of employees in the company is very high, then work for your manager (i.e., do what your manager has asked, even if it is not good for the company).
If the no.of employees in the company is less, then work for the company.

Sometimes, the employees face dilemma whether to do something in the interest of the company or the manager. Manager may say something which is not good for the company. If the employee does not listen to the manager, then the manager may want to get rid of him/her, and the employee's job will not be secure. If the employee just listens to the manager and helps in implementing the bad decisions and finally brings huge losses to the company, then the entire company/project may land in trouble, and everyone in the company/team may lose job.

The control that manager has, is directly proportional to the size of the company. If the company is big, then the manager gets more control, and he/she can take decisions at his/her level, or make others to support his/her (even bad) decisions. If the company is small, then he cannot just do whatever he/she wants to do. Also, if the manager is continuously taking bad decisions, then his/her job will be in trouble.

If the company is small, and if you are not having regular interactions with the top management, don't think that, they will just listen to your manager and they do not know what you are doing.

If the company is big, and if you are having regular interactions with the top management, don't think that, they know what you are doing and they do not listen to your manager.

If the company is big, and if you work for the company, then you cannot work for the company.

Quote of the Day

You will not grow if your manager does not have work.
You will not get promotion if your manager does not have time.

Typical Feedback of Software Engineer

When the developer is just doing whatever is assigned to him/her - the manager feels that, he/she should be proactive.

When he/she is proactive and taking bigger things - The controllers of the project feel that, he/she should not have done that.

When he/she is proactive just at the code level - Other team members of the project see it as a red flag, and raises to his/her manager, and his/her manager asks him/her to stop doing that.

When the developer is just doing whatever is assigned to him/her - the manager feels that, he/she should be proactive.
.
.
.
.
It never ends.