O que é POG ?

Para os programadores de plantão, quem nunca usou um POG ? A Derivação de uma Programação Orientada a Objeto, (Deus Salve o JAVA), como atuante da linguagem Object Pascal usando IDE Delphi, já cansei de trombar POGs por todos os sitemas que trabalhei, "Programação Orientada a Gambiarra", como o mais usado SQL "where 1 = 1" isso pra mim chama "GAMBIWARE"!
As Mensagems são as mais assustadoras possíveis, como:

Seu Programa executou uma operação ilegal e será finalizado!
- Será que isso funciona para o código civil brasileiro?

Seu Sistema causou uma Falha Catastrófica !
- Jesus !!!

E as logicas usadas para um bom projeto?
É só digitar 4 8 15 16 23 42 a cada 108 minutos que o programa vai continuar rodando!
Programador da fundação Hanso que criou a Iniciativa Dharma na Série Lost

Gerente de TI Sobre a a maioria dos clientes operacionais
Mudou a cor da grama, usuário morre de fome!
- conheço alguns que também morrem de fome, se o botão dele não for pink piscando alternadamente para o verde com um intervalo exato de 3,2 segundos, justificando que deve se seguir as "boas normas de programação visual". (mesmo que a função do aplicativo não mude).

Se ninguém reclamou é porque está funcionando!
Programador as 18:00 da Sexta.

Eu li uma em um grande site de vendas online, onde o cliente perguntava para o vendedor, se aquela peça especifica, funcionava no seu computador, a resposta foi digna da melhor pesquisa:
"Funciona sim, pois no site do fabricante não diz em nenhum lugar que não funciona"

O primeiro POG que se tem notícia é datado de 1582 d.C. O nome deste POG hoje é chamado de Ano Bissexto, foi criado pelo Papa Gregório XIII, isso prova que aquela música dos Engenheiros do Havaí está correta: "O Papa é POG". Este POG foi aplicado quando descoberto que a Terra leva 365,25 dias para dar uma volta no Sol, porém nosso calendário tem apenas 365 dias, o que leva a uma diferença de 6 horas por ano.

Para que um programador possa exercer a Programação Orientada a Gambiarras, são necessários alguns fatores específicos, facilmente encontrados em ambientes de desenvolvimento:

• Sistemas originalmente mal projetados
• Clientes chatos
• Usuários chatos
• Falta de vontade
• Falta de tempo
• Gente que pensa que é DBA (normalmente são pessoas chatas, gordas, feias, sem certificação nenhuma e no que fizeram um curso de SQL Básico)
• Arquiteto de software achando que é o máximo(normalmente pessoas, altas, loiras, chatas, arrogantes e metidos a sabe tudo)
• Término do estoque de café/chá
• Aproximação do final da tarde
• Véspera de feriado/fim-de-semana
• Ter o Jackie Chan como chefe
• Ter o MacGyver como coordenador de projeto.
• Governo defecando regras ou MP's que entrem em vigor imediatamente sem dar tempo de atualizar sistemas.

Área comercial vendendo ou pré-vendendo produtos imaginários ou inacabados com "entrega garantida em 30 minutos ou seu dinheiro de volta!"

A metodologia Chuck Norris também pode ser utilizada em sistemas em que se desenvolve na máquina do cliente ou via FTP por um editor de textos qualquer, sem testar e sem fazer backup. Feito para programadores que confiam 100% no código que desenvolvem e que se quer propor um teste é duvidar da sua capacidade. Muito útil para sistemas onde a programação é feita em tempo real para resolver os erros que o cliente acabou de encontrar, antes que ele possa atualizar a página para repetir o erro, o mesmo já estará corrigido e você, ou quem estiver em contato com o mesmo, poderá utilizar de suas técnicas de psicologia para convence-lo de que ele deve ter feito alguma coisa errada na execução anterior.

Os Prazos considerados dos mais variados, desde o Prazo Suicida, onde o programador conhecedor do filme constantine, corta seus pulsos o tempo para, e atraves de um terminal remoto direto do inferno ele implanta o projeto, Deus vendo seu sofrimento o ressucita, o sistema fica pronto em segundos.
O mais real é o prazo sanfona:

Programador:"Devo gastar 24 horas para esse projeto"
Lider Técnico:"O Programador faz isso em 2 horas"
Prazo dado pelo Gerente de Projetos: "40 horas sendo uma previsão inicial"
Tempo realmente gasto: 160 horas

Apesar do comprovado sucesso das metodologias POG, certos gerentes de projeto ainda recorrem a práticas desnecessárias e onerantes, como documentação de projeto. Entra em cena a esperteza de certos programadores e analistas POG.

Documento de Requisitos - Após as primeiras reuniões com o cliente, o vendedor usa os requisitos como entrada para um programa gerador de lero-lero. Assim nasce o documento de requisitos. Ele converte a linguagem coloquial do cliente para uma terminologia que ninguém entende. O cliente assina sem entender, os gerentes passam para os analistas sem ler, e esses fazem o MOG do sistema baseados no lero-lero.

Por fim, o cliente pede 150 funcionalidades a mais, os gerentes aceitam e não cobram, o prazo estoura e a culpa é do desenvolvedor.

Por fim temos toda a metodologia de um projeto:

1. Entusiasmo
2. Desilusão
3. Pânico
4. Busca dos culpados
5. Punição dos inocentes
6. Honra e glória aos não participantes (no final quem não tem nada a ver com o projeto é que salva)
7. Os inocentes que não foram mandados embora, assumem a manutenção do Sistema.

Exemplo Pratico.
Não consegue ver as imagens? Então desligue e ligue seu computador novamente que vai funcionar !!!

Fabiano P.