Vejo que você obteve algumas respostas, mas gostaria de reiterar quanto tempo é desperdiçado contornando os vários limites do governador na plataforma. Por mais que eu goste da plataforma em certos níveis, eu a recomendaria fortemente, enfaticamente, enfaticamente contra ela como uma plataforma de desenvolvimento de aplicativo geral. É ótimo como um aplicativo de CRM superconfigurável e extensível, se você quiser. Embora seu marketing seja excepcional em promover a ideia da Force.com como uma plataforma de desenvolvimento geral, ainda não está nem remotamente perto disso.
A eficiência de ter uma plataforma estável e evitar grandes problemas de desempenho e estabilidade é facilmente desperdiçada em tentar codificar em torno dos limites aos quais as pessoas se referem. Existem tantos limites para a plataforma que se torna completamente enlouquecedora. Esses limites não são limites avançados que você atingirá quando tiver muitos usuários, mas os atingirá quase imediatamente.
Embora geralmente existam técnicas para contorná-los, é muito difícil descobrir estratégias para evitá-los enquanto você também tenta desenvolver a lógica de negócios de seu aplicativo real.
Para lhe dar uma ideia simples de como o ambiente é hostil para o desenvolvedor, considere a "falta de ambiente de depuração" mencionada acima. É pior do que isso. Você só pode ver até 20 das solicitações mais recentes para o servidor nos logs de depuração. Então, conforme você está desenvolvendo dentro do aplicativo, você deve criar uma solicitação de depuração "Novo", selecionar seu nome, clicar em "Salvar", voltar ao seu aplicativo, atualizar a página, clicar de volta na guia de depuração, tentar encontrar a solicitação que abrigará seu log de depuração, clique em "localizar" para pesquisar o texto que você está procurando. São cerca de dez cliques para ver uma saída de depuração. Embora possa parecer trivial, é apenas um exemplo de quão pouco cuidado e consideração foram dados à experiência do desenvolvedor.
Tudo sobre a plataforma de desenvolvimento é uma reflexão tardia enxertada. É notável pelo que é, mas um PITA total na maior parte. Se você não sabe exatamente o que está fazendo (já que você é certificado e tem um conhecimento profundo do Apex), facilmente levará mais de 10 a 20 vezes o tempo que levaria em outro ambiente para fazer algo que parece ridiculamente simples, se é que você consegue ter sucesso.
Os limites do governador são realmente ruins. Você tem uma combinação de vários limites (consultas de banco de dados, linhas retornadas, "instruções de script", chamadas futuras, textos explicativos etc.) e precisa saber exatamente o que está fazendo para evitá-los. Por exemplo, se você tiver um campo de "fórmula" de rollup calculado em um objeto e tiver um gatilho em um objeto filho, ele executará os gatilhos do objeto pai e os contará em relação aos seus limites. Coisas assim não são óbvias até que você passe pelo doloroso processo de tentar e falhar.
Você tentará uma coisa para evitar um limite e acertará outra em um jogo interminável de "quebrar um limite". No processo, você terá que reestruturar drasticamente todo o seu aplicativo e abordagem, bem como reescrever todo o seu código de teste. Você deve ter 75% de cobertura de código de teste para implantar na produção, o que é realmente muito bom, mas combinado com todos os outros limites, é muito trabalhoso. Na verdade, você atingirá os limites do governador ao escrever seu código de teste que não surgiria em cenários normais de usuário, mas que o impedirá de atingir a cobertura.
Isso sem falar em uma série de outras questões. A embalagem não é o que você espera. Você não pode empacotar seu aplicativo e entregá-lo aos usuários sem intervenção significativa do usuário e configuração por parte do administrador da organização. O AppExchange é uma piada total, e eles até começaram a cobrar 5K apenas para listar seu aplicativo. Importar com o carregador de dados é uma droga, especialmente se você tiver gatilhos. Você não pode exportar todos os seus dados em uma etapa que inclua seus relacionamentos de forma que possam ser facilmente reimportados para outra organização em uma única etapa (por exemplo, uma organização dev). Você só pode atualizar um sandbox uma vez por mês a partir da produção, sem exceções, e você não pode incluir seus dados em uma atualização por padrão, a menos que tenha chamado seu executivo de conta para desbloquear esse recurso. Você pode' t excluir dados em massa em objetos personalizados. Você não pode alterar os nomes dos seus pacotes. Certas coisas podem levar váriosdias para serem concluídos depois de solicitados, como um backup de dados antes de implantar um aplicativo, sem relatório de progresso ao longo do caminho e sem muita noção de quando exatamente a exportação ocorreu. Visto que há problemas de sincronicidade de dados se houver relacionamentos entre os dados, há problemas sérios de integridade de dados, pois não existe uma "transação" que pode exportar vários objetos em uma única etapa. Provavelmente, existem algumas ferramentas comerciais para facilitar isso, mas não estão ao alcance de desenvolvedores normais que podem não ter um orçamento enorme.
Tudo o mais que as outras pessoas disseram aqui é verdade. Às vezes, pode levar de cinco segundos a um minuto para salvar um arquivo.
Não quero ser tão negativo porque a plataforma é muito legal em alguns aspectos e eles estão tentando fazer coisas em um ambiente multilocatário que ninguém mais está fazendo. É um ambiente muito inovador e poderoso em alguns níveis (na verdade, gosto muito do VisualForce), mas espere mais um ou dois anos. Eles estão fazendo parceria com a VMware, talvez isso leve aos desenvolvedores um pouco mais de um cercadinho em vez de uma cela de prisão para trabalhar.