Curious Rami

Product managers, marketing managers, sales managers and customers will always push to add new features to your project. It is very hard for developers and engineers to argue against adding new features for many reasons including:

1-Customers and managers will always have a good reason for adding the new features (so they think). They are always so existed about the new features that they can’t listen to you.

2- Customers and managers will argue that you say “no” because you have to do it (in their mind; developers play Desktop Tower Defense all day long).

3-You, developer, are worried that they will go to someone else, and you will no longer be the go-to-guy.

So what to do?

Simply said: Play Their Game.

Managers and customers will always push the developers to add new features with the assumption that the golden three: cost, time and resources will not change.

So here is what you do:

1-Get really excited about the new features

2-Agree to add the new features

3-Congratulate them on coming up with the new features

Here it comes:

4-Tell them, very casually; that the new features will delay the project by 3 weeks and that you will need another tester for 1 week.

The magic:

Managers and customers will immediately stop you and tell you to forget about the new features and put them in the nice-to-have features list where they will stay there forever.

It works, give it a try, and let me know what you think.

As usual, comment, comment, and comment now!

PS: Wrote this post while listening to Dream Theater’s Systematic Chaos. Awesome CD!

When projects are behind schedule; most managers will push their team to work overtime and sacrifice quality in order to ship products on schedule.

Those managers need to understand two points:

1- Working overtime does not fix the problem. As developers/engineers work more hours, their productivity declines. Moreover, sooner or later the team will burnout and hate their job.

2- Sacrificing quality is a short term solution; it will most likely get the manager a promotion or a bonus. However, eventually, the product will fail or the code will break, the truth will rise, exposing the manager’s doings, damaging their reputation and costing the company a fortune to fix all the problems.

What to do when projects are behind schedule? Simple: The only way to successfully finish the project is to cut as many features as possible.

Here is a systematic procedure to accomplish this difficult reality:

1- Stop

2- Admit that something went wrong

3- Make a decision that you are going to do something about it and that failure is not an option

4- Prioritize the project’s remaining tasks (think big - major tasks only)

5- Assign cost, time and human resources required for each task

6- The magic: get rid of as many tasks (features) as possible based on priority, cost, time and human resources required

1, 2, and 3 are lame but required.

50% of all features will never be used and are purely added for marketing purposes, get rid of them.

Let me know what you think, comment, comment, comment now!

Disclaimer: I wrote this post while listening to “Just a Car Crash Away” by Marilyn Manson.

Many companies have a policy to review code to verify that the company’s code standard has been followed.

Here it comes: I believe that code reviews are a waste of time and ineffective.

Spending few hours to review other’s code is not enough. To properly review new code; I believe that developers should spend at lease 20% of the time it took to write the code. For example, if it took five months to write the code, developers should spend at lease one month reviewing it.

Why managers enforce code reviews?

Most managers are aware of the uselessness of code reviews. Managers enforce code reviews because it just sounds good to say that a code review has been done, especially if it is a company policy. Moreover, code reviews have minimal effect on cost, schedule and resources.

Why developers should reject code reviews?

Approving code based on short code reviews only is very risky. Developers will be liable for approving code they reviewed. Developers should never approve code unless they are comfortable that they spend enough time reviewing it.

Moreover, code reviews are usually performed close to the end of the project cycle, even if problems are identified, it too late to fix them and retest the code.

How could you improve the process?

Code reviews are fundamentally ineffective, they don’t work. Here is a better method; make sure every developer believes in the code standard. Review the code standard and update it at least every six months. Every developer should have the opportunity to review and discuss the code standard. When developers believe in the value of the code standard, they will implement it out of habit. Stop reviewing code and trust your developers.

What do you think? Leave a comment.

I recently learned a couple of productive excel tricks in my financial management class. Here they are, enjoy…

Trick 1: Naming cells

It is very useful to name a cell or a range of cells in excel. Instead of calling a cell by its coordinates (e.g. B12 or B12:B17) you can give it a name (e.g. TotalPayments or Payments).
Naming cells is especially useful if you are using cells in calculations across more than one worksheet.

To name a cell or a range of cells:

1- Click on the cell or range of cells.
2- Click on the name box, usually in the upper left corner, and type in the name.
3- Press Enter.

Here is an example with the cell name in the upper left corner and the value of the cell in the upper right corner:

Worksheet 1:

Worksheet 1

Worksheet 2

Trick 2: Using a constant value in multi-row calculations

In the following example, I set the value of C2 = B2*F5. F5 is constant and will be used in every calculation in column C. However, when I click on C2 and drag the formulas down, the value of F5 doesn’t carry over; instead the next rows use F6, F7 and so on.

To fix the problem use C2 = B2*$F$5 as follow:

What do you think? Share your thoughts and tips.