Interesting syntax usage I just discovered:

#include <iostream>

void fn(int x) {
    switch(x) {
        case 0:
            std::cout << "execute only if x == 0" << std::endl;
            if(false)
        case 1:
            {
                std::cout << "execute only if x == 1" << std::endl;
            }
            std::cout << "execute if x == 0 or x == 1" << std::endl;
            break;
        case 2:
            std::cout << "execute only if x == 2" << std::endl;
            break;
    }
}
int main(int argc, char* argv[]) {
    fn(0);
    std::cout << "*****" << std::endl;
    fn(1);
    std::cout << "*****" << std::endl;
    fn(2);
    return 0;
}

In case you missed it, note the "if(false)" at the end of the "case 0:"

renji@shrine:~/tmp$ g++ test.cpp && ./a.out
execute only if x == 0
execute if x == 0 or x == 1
*****
execute only if x == 1
execute if x == 0 or x == 1
*****
execute only if x == 2

Something loosely similar to the trickery used in Duff's Device, I guess. This can be used when 2 cases of a switch have different initial code and the same common code, although using it in production code will decrease readability of the code.

Appraisals - The Most Self-Destructive Process in an Organization.

For a variety of reasons, I believe appraisals count among one of the most self-destructive processes a start-up can have.

Think about the following questions:

• If you are building an organization with the goal of competing against other similar organizations, what sense does it make to pit your own employees against each other?
• More crucially, how will an employee's goals ever be aligned with the company's goals if he is more concerned about a colleague than about the competition?
• Even more crucially, how will you ever nurture a team of all-round rock-stars if you are going to bureaucratically separate them into good and bad players and fit them on some ridiculous bell-curve?

Despite being a huge administrative burden on the organization, every company goes through this ritual very religiously and with mind-numbing regularity.  In addition to being a waste of time and money, it also ensures a drop in productivity while people fill out their self-appraisal forms, employee-appraisal forms, 360-degree appraisal forms and what not.

So why do managers recommend it? For various reasons:

• It shifts the balance of power towards people in the middle layer of management - usually those least qualified to assess performance.
• Their own goals include staying in budget and reducing costs. They will try to reduce increments and bonuses while it is in the company's interest to hire good people and keep them motivated.
• Simply to justify their own relevance to the company.

While it is necessary to have some mechanism where overall team performance and quality of work is judged and rewarded, the traditional way is not the right one. All it serves is to drive up internal politics and, like our education system, homogenize a diverse group. 

On the other hand, there are so many better techniques a growing company can use:

• Reward performance of the team as a whole instead of individuals.
• This creates a greater alignment between individual and company goals.
• If a team member is not pulling his weight, it gets noticed by the rest of the team
• Conversely, he is not worried about the opinion of other individual team members but by the opinion of the whole team.

• Remove the time-periodicity (annual, half-yearly, etc) from the process. How many managers remember what an employee did 6 months ago?
• Instead, tie rewards to goals. Give bonuses and increments when targets have been met, when  a competitor has been overtaken, or simply when a major release has been made.
• Let team members nominate performer of the month. This will encourage team members to work better with their colleagues and automatically throw up born leaders.
• Strongly encourage team members to come forward with their negative opinions any time. There is much more value when a team lead comes to you and suggests that team member X should be let go or reassigned to another team, as soon as it has become a concern for him, rather than wait for the appraisals.
• Have a system of awarding points at the end of each sprint, based on criteria such as
• Did the team member meet his sprint goals?
• Was the task assignment reasonable (for team lead)
• Was productivity/metrics measured properly

All of the above measures will help to genuinely align goals across the company, reward true performance, reduce waste of time on non-productive efforts, and foster team spirit and competitiveness.

You are a typical IT services company.

Ever noticed how near-identical the website of any standard small-to-medium sized IT services company is? They all say the same thing in different words.

Here are a few stereotypical statements:

• We have a well defined SDLC/Agile methodology: No, you do not. What you have is the following:
• Incomplete requirement specs
• Templated design documents
• Superficial project plans
• Inexperienced coders
• Missed milestones
• Artificial deadlines
• We are quality-oriented: No, you are not. Continuing from the above, what you have is:
• A QA team that tests everything manually and whose test cycles are counted in weeks.
• Delays in QA release builds from development team.
• Increasing pressures on QA teams to compromise on their testing to meet above-mentioned artificial deadlines
• fights between engr and QA teams about deadlines and definition of bugs.
• We use industry standard best practices: No you don't. You either:
• do not have a single document that actually outlines what that "best practice" is.
• If you do, it is a vague document created by someone is response to a past crisis.
• It is lying on a backup file server and nobody has actually ever read it after it was created.
• Our engineers are the best: No they are not. You have 1 or 2 "HR executives" who work their butts off coordinating with recruitment agencies that flood you with unsuitable resumes and setting up interviews with overworked senior developers who have their own deadlines to meet.  Your engineers are whoever you could hire in the one-month "ramp-up" period that you wrangled out of your customer.
• We are customer-oriented: No you are not. You have a process that requires at least weekly conference calls with customers because your team is incapable of coming up with the right solutions on their own and want customer validation every step of the way.
• We are low cost: - no, you are not. You have a top heavy team with non-billable mid-level management layer that contributes the most to your project costing. You try to make it justifiable by explaining that they are a shared cost across multiple projects. In times of crisis, this same team will gather in a meeting room and cast accusatory looks at the poor innocent coffee machine lying in the corner.

Are you really different from the rest?

Why C++?

When I was selecting a language for my product Segito, I considered most languages I knew and finally settled on C++ for a variety of reasons. The languages I considered were C++, Java, C# and Python, while others like Ruby and PHP were not in the running.
The reasons for choosing C++ are listed below, in no particular order:

Cross platform support

The biggest issue I had with the non C++ languages was support and availability of the dependencies. For each of those languages, there was at least one platform that did not support it, or had only sketchy support.

• The JRE is not available on iOS (there are plans to support it by Sun/Oracle) and Symbian
• .NET is not available on Android, although there is a recent commercial Mono 3rd party port.
• Python for iOS is available only as a 3rd party port.

C++ on the other hand, enjoys native OEM support on Windows, Linux, OSX, Android, iOS and Windows Phone 7 (speculated for 8 as well). Sadly, all VM based languages were developed with the intent of providing cross-platform support.

Size/Speed

The second biggest advantage C++ has over the rest is size, including dependencies. The current win32 release of Segito is about 1.5 Mb (800Kb installer) while the OSX .app package is about 2.5Mb.

For everything else, while the size of the executable would have been small, the runtime environment would have been significantly larger.

• The latest JRE for Windows is about 15Mb
• The .NET 4 runtime for Windows is about 24Mb
• The Mono runtime for OSX is 84Mb

C++ allows us to write bare metal apps that contain nothing more than what is needed.

IDE

Almost all target platforms have free, native OEM supported IDE's for C++, while the rest have at best, third-party support.

• Windows has Visual Studio Express Edition which is extremely fast and lightweight. The 2008 edition running in a Windows VM on OSX starts up in less than 1 second and a full rebuild of the whole app takes less than 30 seconds.
• OSX and iOS has Xcode, although it is a bit of an acquired taste for someone from a Windows/Linux  background.
• Linux has KDevelop and QtCreator, which although third-party, are both excellent IDE's in their own right.

A big disadvantage here, however, is the need to maintain multiple projects but that is outweighed by the rest of the advantages.

Static typing

While static typing in programming languages may not seem like a significant factor, very often the business importance is missed. Dynamically typed languages are very useful to churn out applications quickly - one can use Python to write an application much faster than using C++.

But what happens when the start-up gets funded and goes to the next level? When the initial founder-developers are replaced by a team of 20 new developers, the new team does not have the familiarity with the code base like the original developers did. This is when the bug count start increasing. For example, it becomes easy to call functions with parameters of incorrect type and this will result in subtle bugs that will never get discovered until they bomb at run time. If you are lucky, they will get caught in the QA phase, and if not, your customer will find it, resulting in loss of productivity and goodwill.

As the team size grows and/or there is a churn in the team, such bugs in the code will increase exponentially. 

With statically typed languages, these errors get caught at compile time. No doubt, good software engineering is the sum-total of many different best practices, but this is one class of error that can very easily be eliminated by letting the compiler do the work.

One common counter to this is that such errors can be caught by writing good unit tests, but in my opinion, that's a self defeating argument. If you are going to save time using Python and spend it writing unit tests, you have achieved nothing.

Skill-set availability

This is an advantage and a disadvantage at the same time, more of the latter. Most educational institutes teach C++, but most organizations use anything but C++. So the probability of finding good and experienced C++ programmers is quite low, but c'est la vie!
The advantage is that C++ training is not a viable mass-market business for software training institutes so although the number of resumes processed will be low, the hiring-to-interview ratio will be much higher.

Summary

That said, I am not a hardcore all-or-nothing C++ fanatic. The above was my thought-process for selecting a language for a product that is expected to run on a wide variety of desktop and mobile platforms. The enterprise server component of Segito is written in C# and there will almost certainly be a Java version in the near future.

I like to compare C++ with the English language: both have their own warts, both have more exceptions than rules, both can be extremely frustrating to learn and people complain about both endlessly. But if your business depends on a community and you need a common language that everyone understands, it is the only option available to you. No matter how perfect your native language may be.

Open source analogy

Very often, I get asked about the reliability of open source, and have wondered what is the best analogy to explain it. I had an epiphany the other day - medical science.

When we are ill we go to the doctor, who makes a prescription. And when we hold a pill and a glass of water in our hand, on what basis do we have the confidence that this pill will cure us, or at least that it won't kill us? After all we haven't personally verified it, have we?

It is on the basis of the transparency in the process of developing it. This includes basic research, publications, open peer review, criticism, field trials on animals, government approvals, human trials, well defined standards in the manufacturing process, etc.

Likewise, the open source software development process provides transparency. You may not be able to personally verify the source code for the product you are using, but if it is popular enough you can be assured that it has been seen by developers and other experts around the world, and unless there was a global conspiracy involving all of them, the product you are using is reliable.

Why didn't I know about it?

Why do most organizations, especially mid-level start-ups, have complex processes that virtually dictate how things must be done? And usually why is there a high level of discontent/contempt for processes among employees?

Because when a manager asks "There was a problem? Why didn't I know about it?" the right answer is "Because you were not there!". Sadly, the usual response is to add more cruft into the system to "ensure that management becomes aware of a problem as soon as possible".

So now you have the team wasting time preparing and sending status reports by email to the manager, whose email software automatically filters these reports to a separate folder that he ignores, until the next time when there is a problem and he asks "Why didn't I know about it?".

This time the status reports have to be consolidated by the Team Lead into an spreadsheet, with "issues" marked in red, so that the manager can see them "at a glance".

Rinse, lather, repeat, until The Process becomes a nightmare of statuses, reports and meetings that drain the resources and productivity of the start-up.

No doubt, every organization need a process to ensure that team members know what they should be doing, and others know the progress of each team. The most effective process is one that achieves this and gets out of the way. The key to this, I believe, is to maximize automation, where team members do not have to spend more than 5 minutes in their day on updating status, and all reports are generated on the fly for anyone who wants to see it.

And a manager most definitely should not require a process to know when something went wrong - he should have seen it coming before it happened.

Are humans fundamentally vegetarians or non-vegetarians?

I believe humans are non-vegetarians from an evolutionary perspective.

The animal kingdom is split into predators and prey and there is one characteristic shared by all members of each group, regardless of species. That is the position of the eyes.

All prey have eyes at the side of their head, to get a wider view of their surroundings when grazing and looking out for predators. Whereas all predators have eyes at the front of the head to focus better on their prey during a chase. This applies everywhere - mammals, fish(sharks), birds(eagles), reptiles and so on.

Guess which group humans belong to?