Curious Rami

There are two flavors of software (and firmware) tests: the functionality test plan and the try-to-break-it test.

The functionality test plan involves writing test plans to test functionalities and requirements. The try-to-break-it test involves using the software in an unexpected manner without a pre-written test plan.

Managers usually lobby for the functionality test plan and developers usually lobby for the try-to-break-it test.

Both tests are important and both tests must be performed after every new release.

The try-to-break-it test verifies the quality of newly added functionalities. On the other hand, the functionality test plan verifies that all previously added functionalities are still working.

Manager: Why do we need the try-to-break-it test?
Developer: Because we need to test new functionalities now.

Developers: Why do we need the functionality test plan?
Manager: Because we need to test current functionalities in the future after new releases.

The functionality test plan should be updated after running the try-to-break-it test to include tests for all new functionalities.

 What do you think?

I am not sure if this story is true or false, however it makes a point that everyone in your organization should be informed about the dangers of the internet and should be trained to spot and avoid hackers’ attacks.

The attack strategy was the easiest one.

The usual milw0rm downloaded exploit delivered by email/click-on-the-link/open-browser/click-on-this-animated-icon/back-connect to some employee of Bloomsbury Publishing, the company that’s behind the Harry crap.

It’s amazing to see how much people inside the company have copies and drafts of this book.

http://seclists.org/fulldisclosure/2007/Jun/0380.html

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.

I just finished a week long course on staffing from Dalhousie University. Mr. Alex Filimon taught the class and he did a great job. The course focused on HR management issues including evaluating and forecasting current and future recruitment requirements, preparing recruitment proposals, preparing job descriptions and requirements, advertising, screening, testing, interviewing and making hiring decisions. In one week, I attended 40 hours of lectures, wrote 3 papers and took 1 quiz. Over the next 2 weeks I have to write a complete HR plan to recruit for a position of my choice, most likely an electrical engineer.

I learned a lot from this course, and I recommend that every MBA student should take a staffing class. I learned that the recruitment process is a scientific process. I learned that it is very easy to discriminate even when you don’t mean to (I did not like the way he laughs is discrimination!). I learned that you have to document the whole recruitment process and prove that every interview question has a purpose and is related to the job requirements. I learned that you could be sued based on the interview outcomes only. I learned that you could be sued if you fire an alcoholic because alcoholism is a sickness in most provinces.

What you need to do:

• Consult an HR professional before you start the interview process.
• Consult a lawyer if you have any bona fide job requirements (example: must be male, or must be age 21 to 25).
• Consult a lawyer before you fire an employee.

Quiz:

Do you think video resumes are a good idea?

After you answer, read the following article form Business Week on the potential consequences of watching video resumes:

Beware Of That Video Resume
Employers should think carefully before pressing “play” on the online video résumés job seekers are increasingly sending out, some labor attorneys warn.

Cheryl Behymer, a partner at national labor and employment law firm Fisher & Phillips, says she advises her clients to proceed with caution to be sure they’re not making themselves more vulnerable to charges of discrimination. “You’re seeing a physical representation of the candidate, what their race is, their national origin, their age,” she says. “That potential applicant might say: The reason you didn’t [interview] me is because you can tell I’m a minority.’”

The idea of first looking just at a candidate’s qualifications, Behymer says, is to help prevent the filing of a failure-to-hire claim, which can arise if an employer is suspected of discriminating against an applicant who belongs to a “protected class” a minority individual or an older person, for instance. It helps at this early stage of the hiring process, she says, to keep information about race and age, for example, separate from a candidate’s skills and qualifications.

One process Behymer recommends: Have initial résumé screeners omit the video when they send along a candidate’s other materials to the manager actually doing the interviewing or hiring.

Like Behymer, Garry Mathiason, a senior partner at leading employment firm Littler Mendelson in San Francisco, says that employers should never require video résumés from candidates. That’s tantamount, he says, to asking questions about race or age “that at this stage in the process are unlawful.”

But, says Mathiason, “if the applicant decides to send in that information through a video résumé,” he doesn’t agree that an employer has to avoid it. Companies “do take on some additional, limited risk” by viewing an online video résumé, he says. But they can also gain from assessing certain traits in candidates—”how confident they are, for example.” Still, he says, to be safe, “I’d err on the side of including in my interviews all those who meet the job’s objective criteria.”

By Jena McGregor

http://www.businessweek.com/magazine/content/07_24/c4038004.htm

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.

Checkout Anne Zelenka’s review of web based mind mapping apps: http://webworkerdaily.com/2007/03/08/three-web-based-mind-mapping-tools-reviewed/