Um pesadelo de T.I

Por coincidência, já escrevi algo sobre este problema no meu blog (quase a mesma experiência): http://www.itexto.net/devkico/?p=273

Agora, sabe o que eu penso? Sério mesmo? (já aviso: discordo da postura dos seus dinossauros completamente (vide meu post))
Você está ai contando que eles tinham um sistema de 30 anos e queriam portar para outra plataforma.
Em 99% das vezes em que vi isto ocorrer, foi um desastre, e sinceramente, nestes casos, sou contra.
Não vejo porque matar um sistema antigo só porque foi feito em fitas perfuradas quando o mesmo atende a empresa.

O que as pessoas se esquecem é que por trás daquele código “horroroso” normalmente há um MONTE de conhecimento implícito presente.
Cada um daqueles “ifs nojentos” é na realidade um pequeno aspecto da cultura organizacional da empresa.

Ai entra o papo de “não atende mais”, mas garanto uma coisa: apenas uma pequena porção do mesmo não atende.
Se o que não atende são novas funcionalidades, acho mais interessante implementar estas novas funcionalidades (mesmo assim, se for o caso) em outra linguagem, mas mantendo o bichão velho intacto.

Já vi casos de empresas migrando sistemas legados em COBOL para Java (ou C# ou qualquer outra mais “nova”) e dando com os burros na água.

E vc demorou quanto tempo pra pular fora dessa barca furada?

O pior que eu pensei a mesma coisa… hahaha

Já vi essa série.

Lost.

hahaha e uma vez eu fiquei P*** por nao poder usar operador ternario hahaha é amigo ta numa situação pior q a minha hehehe

Esse tipo de prática e postura é inaceitável.

Pessoas com ideias como essas deveriam ser expostas como fraude profissional. É o mesmo nivel de um médico violentar uma paciente ou um cozinheiro mijar na soupa. Eu coloco à votação do todos se acham ético que o nome dessas pessoas e empresa que as mantém no cargo seja divulgado.

Não podemos continuar aceitando esse tipo de coisa. Isso não é apenas um detrimento à nossa profissão , mas a todos os profissionais e à inteligência e cultura humana como um todo.

EU já passei por um inferno da TI também!
Trabalhei em uma empresa de sistemas
financeiros onde o dono achava que o Delphi era Clipper, e que o
Oracle era dbf!
E ele ainda tinha cultura bancária de mainframe: para cada
funcionalidade ele criava um programa (um executável).
Os programas tinham nomes bacanas como proc1345a, fin789c, etc.
As tabelas no banco tinham nomes tão esdrúxulos quanto os programas,
pois foram migradas diretamente do DBF (que só aceitava 8 caracteres
no nome do arquivo), e 8 caracteres no nome dos campos.
Trabalhei lá durante 8 meses, e durante estes 8 meses, trabalhei como
um “pedreiro da informática”, recebendo papéis com instruções no
estilo “Faça update do campo a12345 da tabela x7898…”. Eu fazia, mas
até hoje não sei o que fiz durante estes 8 meses que passei lá. Às
vezes, não tinha nem condições de testar o que fazia, pois eu não
sabia para que servia (as funcionalidades eram isoladas,e não
liberavam a informação para você saber como o o módulo em que você
mexeu afetava os outros programas).
Foram 8 meses de inferno.
E esta empresa hoje em dia entrega essa porcaria de software mal-feito
para grandes (enormes) clientes até no estrangeiro (vários países da
América Latina).
A informação era represada de tal forma que apenas os “poderosos” (funcionários mais antigos)
tinham acesso a ela, provavelmente para continuar nos seus cargos…
Em suma, era uma merda…

huahuahuaia

q comédia…

soh eu to me cagando de rir dessa estoria?

isso daria um sarcastico quadrinho do Dilbert

pois é Sérgio…

depois quando eu falo em regulamentação profissional, voce vem cheio de “poréms”

Isso é normal e não diz respeito à TI, e sim a qq departamento organizacional.

O cara que esta na empresa ha +10 anos não quer que um novato chegue com idéias revolucionárias (que muitas vezes o veterano não entende pois é coisa nova e ele é um dinossauro que não se preocupou em atualizar-se)

Então se ele permitir que vc recém formado com idéias maravilhosas ofusque o brilho dele dentro da empresa. Meu amigo ele com certeza vai te reprimir.

Eu já passei por isso várias vezes, o que eu faço é cair fora da empresa e buscar alacançar os meus objetivos.

Outra:
uma vez tinha uma stored procedure do Oracle dando um erro.
Umas 400 linhas de código macarrônico.
Deram para eu analisar.
As 400 linhas de código eram para adicionar e decrementar datas…
Simplesmente pegaram os algoritmos do Clipper e transformaram em Oracle…
SEM SABER QUE O DELPHI TEM FUNÇÕES PARA FAZER ISSO…
COM UMA LINHA DENTRO DO PROGRAMA VOCÊ RESOLVIA ESTE TIPO DE PROBLEMA, SEM TER DE EXECUTAR A TAL STORED PROCEDURE…

To rindo pra não chorar! Infelizmente temos q ler esse tipo de coisa hehehehe!

Abraços!
Leonardo Gloria

Por outro lado, estou cansado de ver equipes usando a linguagem da moda pra criar camadas e mais camadas inúteis com o pretexto de que estão fazendo “design OO”. Vai ver que era esse o caso e eles preferiram adotar uma solução mais simples do que a proposta por vcs.

O problema não é TI, é administração.

Sempre que um grupo novo de pessoas chega na empresa, os antigos tem a sensação que após a “renovação” serão descartados. Isso vale para qualquer processo novo, não só para os tecnológicos.

E o pior, não são tão desprovidos de razão pois, não raro, isso realmente acontece.

Só se a “suposta equipe” que vc citou for imatura o suficiente para tomar uma atitude dessas. Não acho que seja o caso.

Outra para rir:
Trabalhei em um projeto onde havia necessidade de um parser de expressões matemáticas.
Escrevi a classe, funcionou perfeitamente.
Então, um ser do além (dizer ser analista) apareceu-me com uma especificação descrevendo um “Cadastro de Operaçoes Matemáticas” para ser utilizado pela minha classe.
O que a tal classe de cadastro fazia?
Ligava um operado a uma operação matemática.
Ou seja, colocando tal porcaria no software o usuário poderia fazer cagada, e cadastrar o operador ‘+’ como fazendo qualquer outra operação além da soma!

Outra:
Em uma outra empresa, colocaram os cadastros todos na mesma tabela, com um flag para diferenciar o tipo de cadastro.
O gênio que fez isto viu que todas as tabelas iriam ser apenas código/descrição, e decidiu fazer essa merda.
Havia mais de dez tipos de cadastro dentro desta tabela.
E ele achava-se o “esperto”, por ter economizado umas tantas tabelas.

Ahahha…

Lembrei agora de um chefe meu que colocava o nome das tabelas em numeros (EX. Pedido = 1000, linha pedido 1010), porque assim, segundo ele, ficavam mais legivel e intuitivo :shock:

Outra:
Uma vez fui chamado por uma empresa que tinha um software de controle de vendas que havia parado de funcionar (eles tinham os fontes).
A reclamação do cliente era que ele não conseguia emitir relatórios que abarcassem mais de um mês de vendas (por exemplo, entre 01/01/2009 e 30/06/2009).
Dei uma olhada, e descobri a coisa mais tosca que já vi na minha vida: o POGramador tinha criado um banco de dados (Firebird) para cada mês!
Havia 12 bases diferentes, uma guardando os dados de cada mês do ano!
Obviamente, não aceitei dar manutenção na m…

Em 1997 fui contratado por uma empresa para começar a desenvolver sistemas em Delphi.

Quando cheguei lá, fui apresentado ao “Power Builder” (não queiram saber).

Durante um mês, diariamente, eu perguntava: “Quando vou parar de ver esse power builder e começar a escrever em Delphi?”

Abandonei o emprego, nem o salário desse mês que fiquei lá vendo “Power Builder” eu voltei pra buscar.

Edit: Gramática.

Já passei…e foi mais de uma vêz. E estou correndo sério risco de passar de novo.

Na minha opinião a solução nestes casos é procurar outra oportunidade. Se possível, tente não fechar as portas desta, no futuro ela pode estar melhor.

Como já foi dito, isto não é uma coisa que acontece apenas em contexto onde existe grande porte; a idade dos atores também é irrelevante.

Eu diria que este é um daqueles momentos que o profissional tem que ter sangue frio e começar a refletir sobre:

1. Os caras da “velha guarda” não vão aprender / aceitar a nova tecnologia de uma hora para outra; especialmente se for JAVA. E eles SABEM DISSO MUITO BEM, acredite; só não vão confessar para você.

2. Em boa parte da história a “velha guarda” se ferra com este processo. A velha história do “não se adaptou”, o momento da vingança para alguns com certo poder, pois quem detem informações importantes para se manter no emprego pode estar fragilizado. De novo, eles SABEM DISTO também.

3. A “nova guarda” muitas vezes chega com muita força e se eles derem bobeira “vão dançar” mesmo.

4. O processo de instauração de uma nova tecnologia NESTES CASOS leva ANOS; primeiro a “velhar guarda” irá apanhar por conta do que já foi dito, a “nova guarda” irá apanhar por não haver planejado adequadamente a incursão e nem ter conseguido conquistar aliados significativos e etc…
   …

Em uma empresa que passei, os causadores destas mudanças transformaram a “velha guarda” em analistas de negócios e “líderes” de equipe (para quem éra apenas analista programador ou apenas programador ficou bom demais - o salário aumentou bastante também); o detalhe era que eles não deveriam se meter com as questões tecnológicas. O negócio deles éra transmitir / obter informações, negociar prazos, e muitas vezes fazer parte do planejamento e etc… Para resumir…eles queriam apenas receber o que foi combinado funcionando.

flws

ViniGodoy:

O problema não é TI, é administração.

Sempre que um grupo novo de pessoas chega na empresa, os antigos tem a sensação que após a “renovação” serão descartados. Isso vale para qualquer processo novo, não só para os tecnológicos.

E o pior, não são tão desprovidos de razão pois, não raro, isso realmente acontece.

É uma cilada, Bino!!!

FrancoC:

pois é Sérgio…

depois quando eu falo em regulamentação profissional, voce vem cheio de “poréms”

E o que especificamente isso tem a ver com regulamentação?

Regulamentação só vai garantir que esses dinossauros estejam respaldados pela lei.

É uma cilada, Bino! [2]

Já trabalhei em empresas onde era registrado com salário mínimo na carteira, e o resto vinha tudo por fora.
Isso continua acontecendo muito?
Trabalhei 3 meses desta maneira, pois acabei vendo que o único prejudicado era eu.
Aqui em Curitiba também tem muita empresa que quer contratar como PJ pagando salário de CLT!
Tem uma grande empresa de 3 letrinhas que ligou-me ontem fazendo uma proposta de contratação flex: apenas uma mixaria em carteira, uma parte totalmente por fora, e o resto via cartão bancário…
Observação: o salário era normal de CLT…
Era para trabalhar com Java e C++, e exigia fluência em inglês…

E eu achando que o projeto de um CRM em PHP que participei que era bizarro.

Tinha que desenvolver tudo sem Orientação a Objetos(até aí engulível, pois já vi projetos desenvolvidos com programação estruturada que são bons) e o pior: “Sem MVC”. Se eu tinha que criar um tela nova para cadastrar alguma coisa, o HTML, o código e o SQL tinham como padrão ficar no mesmo arquivo e misturado. Quando fui questionar isso, sabe o que me falaram? “Não dá para usar OO e muito menos separar as coisas em arquivos, pois fica mais difícil dar manutenção depois, pois as coisas vão ficar em lugares diferentes”. Mas eu usei o argumento: “Esses lugares diferentes vão ser convencionados. Tudo vai ter o mesmo nome em cada lugar. Ou se acharem complicado ainda, vamos criar um padrão ou procurar algum para desfazer essa maçaroca, que isso realmente não tá bom”. Mas eles diziam: “É mais simples tudo misturado. Se eu quero alterar um lista, o SQL, o HTML e a lógica vão estar no mesmo bloco de código”. Parecia que leram o artigo de POG Patterns da Desciclopédia e levavam aquilo a sério. Então era aqueles arquivos “lindos”, que começavam com código PHP, tinha um bloco HTML, seguido por Javascript, que depois tinha um bloco PHP com uma SQL, e depois tinha um bloco HTML denovo. Em telas com mais regras de negócios, tinhamos aqueles arquivos de 10000 linhas, misturando HTML, PHP e SQL e nem ao mesmo usar functions. Se um código servia para 2 telas, ‘por padrão’ teriamos que copiar nas 2 telas, pois o famoso ‘vai que um dia’ entrou em ação. E nesse caso era ‘vai que um dia essa funcionalidade mude para 1 só caso’ e nos outras telas vai dar problema. E pior que era um CRM de uma empresa conhecida. E nem dá para culpar a linguagem como muitos fazem, pois com PHP, como com qualquer outra linguagem em que o programador não seja um espírito de porco, dá para fazer coisa bem feita.

Ps.: O controle de versão se chamava “QAFECV”(Que a Força esteja com você). Não existia. E quando e precisava, era criar um “.old”, “.old2”, “.old3” do arquivo em questão. Era uma pasta mapeada na rede.

J2Alex:

FrancoC:

pois é Sérgio…

depois quando eu falo em regulamentação profissional, voce vem cheio de “poréms”

E o que especificamente isso tem a ver com regulamentação?

Regulamentação só vai garantir que esses dinossauros estejam respaldados pela lei.

Exatamente.
Não é um problema de regulamentação, é um problema de ética profissional.
Os cozinheiros não tem sua profissão regulamentada, mas um erro pode matar várias pessoas (intoxicação, alergia alimentar,etc…).
Mas ele mantém uma ética profissional entre si e sabemos (nós , pessoa leigas em cozinha) distinguir os bons dos ruins.

Se um cozinheiro faz asneira ele é despedido. E se ele faz muita asneira (do tipo quase matar alguem) é dificil encontrar emprego em outros lugares.

É este tipo de coordenação entre os profissionais de desenvolvimento que faz falta e não a regulamentação de um governo que segue uma mentalidade dos anos 50 e é cego aos problemas específicos da nossa profissão.

Fora tudo isso tem o problema do profissionalismo pessoal de cada um. Um cara que comanda fazer certo tipo de coisas ou que pensa que programar hoje em dia é comparável a programar para calculadoras, clipper+dbf, ou mainfaime é um mau profissional. E deve ser removido do mercado ou reciclado. Como a reciclagem é dificil, a remoção é o que sobra.

J2Alex:

FrancoC:

pois é Sérgio…

depois quando eu falo em regulamentação profissional, voce vem cheio de “poréms”

E o que especificamente isso tem a ver com regulamentação?

Regulamentação só vai garantir que esses dinossauros estejam respaldados pela lei.

Concordo plenamente, regulamentacao é pra sustentar vaga de quem nao consegue se sustentar sozinho. Profissionais competentes nao precisam ter medo de perder vaga, eles nao perdem.

Pra mim quem precisa de lei pra manter o emprego, pelo menos na nossa area, nao devia nem estar no mercado. O exemplo do autor desse topico é um onde os dinossauros se dariam bem com a regulamentacao.

Mais uma história:
Trabalhei em uma grande instituição de ensino, em que os sistemas de gestão eram LENTOOOOOOOOS.
Investigando as causas, fui ver várias bizarrices no banco: falta de índices, campos que deveriam ser numéricos por questão de performance eram do tipo varchar (ou mesmo char)…
Para ter uma idéia, o cálculo da folha de pagamento da instituição demorava 8 horas para ser feito.
Levantei tudo que eu precisava fazer, e fui apresentar para o reitor e seus filhos.
Um dos filhos do reitor era “formado” na àrea.
Quando comecei a mostrar os índices que precisavam ser criados, o tal filho do reitor, “especialista em desenvolvimento de software”, e que dava aula na faculdade (pasmem), veio com a pergunta:

• Mas a criação de índices não vai fazer aparecer erros no software?
  Quando falei que não, ele duvidou… Tive de explicar detalhe por detalhe do porquê isso ser impossivel de uma criação de índice ocasionar erros em um software. Uma hora tentando convencer o cara.
  Com todas as otimizações feitas no banco, o cálculo da folha passou a ser feito em 12 minutos…

Não é verdade que a regulamentação protegeria esses profissionais.

Como ele conta na estoria é um empresa consolidada com algumas boas décadas ai de mercado. Se eles estão trocando sua base tecnológica deve haver uma série de fatores para isso. E na verdade, eles nem devem migrar tudo pra XPTO, manter sistemas legados hj em dia não é um grande problema. Para isso existe CORBA, DCOM e Webservices. Na verdade em Engenharia de Software a maioria dos autores pregam que o que for possivel reaproveitar deve ser reaproveitado.

È exigencia de clientes, falta de profissionais especializados, etc.

Agora uma vez que eles optaram por utilizar Java, C# ou C++ em alguma ponta de suas soluções, terão de utiliza-lo 100% O.O. e seguir as mais recentes práticas e padrões do mercado.

Sob a pena de serem punidos por imperícia, negligencia, etc. Lógico, se existisse um autarquia com essa responsabilidade na área de TIC.

Meu amigo serathiuk …

Aqui também é assim.

Eles não aceitam usar o controle de versão.

Sugerimos no Subversion.

Disseram que não conhecem, e que pode não ser seguro.

O cara disse:

“Eu faço meus backups a tempos só com o Zip e isso para mim satisfaz. Tenho maior controle.”

É só ir comentando o código ao invés de deletar ou fazer modificações e ZIPar, porque a porcaria vai ficar bem inchada.

FrancoC:

Não é verdade que a regulamentação protegeria esses profissionais.

Como ele conta na estoria é um empresa consolidada com algumas boas décadas ai de mercado. Se eles estão trocando sua base tecnológica deve haver uma série de fatores para isso. E na verdade, eles nem devem migrar tudo pra XPTO, manter sistemas legados hj em dia não é um grande problema. Para isso existe CORBA, DCOM e Webservices. Na verdade em Engenharia de Software a maioria dos autores pregam que o que for possivel reaproveitar deve ser reaproveitado.

È exigencia de clientes, falta de profissionais especializados, etc.

Agora uma vez que eles optaram por utilizar Java, C# ou C++ em alguma ponta de suas soluções, terão de utiliza-lo 100% O.O. e seguir as mais recentes práticas e padrões do mercado.

Sob a pena de serem punidos por imperícia, negligencia, etc. Lógico, se existisse um autarquia com essa responsabilidade na área de TIC.

Você está dizendo que alguém poderia ser punido porque não fez código 100% orientado a objeto ou porque não seguiu “as mais recentes” práticas de mercado?

E desde quando essas questões são mensuráveis assim de forma tão simples e objetiva? Desde quando as mais recentes práticas devem ser consideradas, inquestionavelmente, as melhores? E desde quando padrões de mercado devem ser impostos (se o padrão é JPA, eu não posso usar Hibernate)?

Se você desenvolve aplicações java pra celular você é obrigado a utilizar certas práticas que seriam ridículas para aplicações normais devido às restrições de memória dos aparelhos. A mesma coisa para aplicações embarcadas. Padrões e práticas não são regras que não podem ser quebradas.

O bom profissional precisa justamente saber diferenciar onde uma ou outra solução é melhor. E isso pode envolver muita pesquisa e trabalho, até que se defina a melhor solução para um dado problema. E isso nenhuma autarquia teria condições de julgar, pois não basta criar um manual de regras que diz, por exemplo, que “segundo a lei 12345 parágrafo 123 inciso 69, todo ‘analista de sistemas’ que sugerir a utilização de Struts 1, deverá ser ser severamente punido, por prática de ato prejudicial à saúde mental de sua equipe de desenvolvedores”.

Formar um conselho pra garantir que o software seja OO? :shock:

Essa foi a coisa mais engraçada que li no GUJ nos ultimos tempos. :lol:

Acho que sou muito extremista, mas eu nem ficaria até o fim da reunião…

MauroOliveira, você ainda continua lá? Se continua, essa forma de trabalhar realmente deu certo? Já faz quanto tempo?

Concordo.

Nem tudo deve seguir o modelo MVC.
Existem casos que sim, e outros onde não seria muito interessante.

Também concordo que não devemos ficar escravos da OO e Design Patters e sermos obrigados a usar tudo o que é novo, só para “ficar bonito” ou para dizer que usa…

Cada projeto tem as suas particularidades…

Mas, no caso dessa empresa que eu estou falando, nem queriamos implantar coisa muito nova não…

Eu estou falando de coisa simples, como por exemplo “tipos enumerados”.

Tinha um monte de “IF (TP_SIT = “RF”) OR (UTT = “UC”) AND (SST_JFX = 3 OR SST_INADIM = 7)…”.

Trocar esses números e literais por tipos enumerados com nomes sugestivos com certeza tornará o código muito mais legível. E isso, convenhamos, não arranca pedaço… Ainda mais porque não estamos falando em mudar código. Afinal, estavamos escrevendo uma aplicação nova, em outra linguagem… Ninguem queria meter a mão na aplicação deles não. Só queriamos mais liberdade para fazer a nossa.

Mas…

sim, ainda estou lá.
9 meses.

se está dando certo?
sim e não.
sim, porque querendo ou não, o sistema está saindo.
e não, porque pra dar manutenção no futuro vai ser ruim…

o que me segura lá são duas coisas:

• fica a 25 minutos da minha casa, e no contra-fluxo. não pego nada de transito.
• salário acima da média. ando pesquisando e ninguém paga o que eles pagam.

estou aproveitando o salário e tempo extra que tenho para pagar cursos bons, estudar e tirar algumas certificações…

é o que consigo tirar de bom da empresa.

lá dentro eu faço trabalho de pedreiro, mas em compensação essa é uma das épocas que mais consegui estudar e tirar certificações.

é a forma que encontrei para não “emburrecer”.

Não, não estou dizendo isso.
Também em momento algum eu disse que ao utilizar Hibernate no lugar de JPA voce esta degradando a qualidade do software, ou que uma arquitetura em MVC é melhor do que Pipeline.
Vocês tem um raciocinio muito raso sobre a engenharia de software.
Imagina uma lei proibindo o uso de Struts 1.
Cada coisa que eu leio aqui.

FrancoC:

Não, não estou dizendo isso.
Também em momento algum eu disse que ao utilizar Hibernate no lugar de JPA voce esta degradando a qualidade do software, ou que uma arquitetura em MVC é melhor do que Pipeline.
Vocês tem um raciocinio muito raso sobre a engenharia de software.
Imagina uma lei proibindo o uso de Struts 1.
Cada coisa que eu leio aqui.

Mas foi voce quem afirmou que se houvesse regulamentacao essa situacao descrita nao aconteceria. Eles apenas ironizaram isso. Eu, sem ironizar nada, pergunto porque nao aconteceria. O que numa possivel regulamentacao iria impedir que isso ocorresse?

FrancoC:

pois é Sérgio…

depois quando eu falo em regulamentação profissional, voce vem cheio de “poréms”

isso nao tem a nada a ver com regulamentaçao de profissão…
o gde problema é falta de aceitar opinoes dos outros e ouvir outro lado da moeda sao pessoas com pouco ceticismo e raciocino critico, como as opinioes destas pessoas sao unicas e verdadeiras…

Na verdade não impediria que coisas assim acontecessem, mas de certa forma seria coibido.

Imaginem que inves de produzir sistemas de informacao gerencias, fosse um software que controla a distribuicao de energia do país. Dai o sistema com alguma falha de vazamento de recursos diante de uma sobrecarga de dados no servidor derruba o sistema. O páis inteiro está na escuridão (qualquer semelhanca com fatos reais é pura coincidencia). Ai as autoridades vao atrás da EDP Bandeirante e descobrem que o sistema era fonercido pela empresa de Joãozinho. Joãozinho ganhou da concorrencia pq jogou o preco para entregar o produto para a metade do que a media que havia sido orçado pelos concorrentes.

Joãozinho afirma que essa falha que ocorreu foi fruto de um causalidade, e usa a forte argumentação de que é impossível fornecer um sistema 100% livre de falhas. È um argumentação forte porque é absolutamente verdadeira.

Se houvesse um orgao com competencia ele entao realizaria um auditoria na suposta “fabrica de software” de Joazinho e descobre que lá não há processos estabelcidos, controle de qualidade, seus profissionais estao sendo mal remunerados, não há reciclagem na formacao destes, além uma serie de outros problemas.

E aí quem paga o pato?

VOu dar um exemplo mais trivial pra voces. Eu ja vi um bom cirugiao plastico dizendo que de cada 100 pacientes que ele opera 1 morre. Isso pq ele eh um bom profissional, e jamais fora cogitado de cassar sua carteira profissional. Agora existem médicos por ai que sao verdadeiros acougueiros e para que sejam cassados mesmo assim é um processo extremamente minucioso, e o corporativismo tende a proteger o maximo possivel sua classe.

Voces defendem que na produção de software nao deve haver responsabilidade legal, faz-se o que quer, como quer, com o custo que se deseja.

O fato é que existem métricas, e é possível medir e avaliar.

Mas eu vou dar uma congelada nesse assunto aqui no GUJ pq logo logo vao taxa-lo de “flamewar”, seja la que diabos eh isso. Entendo que é um assunto que voces o fazem ser polemico, mas talvez nao seja o proposito deste canal discussoes deste nivel. Sem mais.

É algo muito fácil de se entender…

O antigos que lá estavam não queriam colocar o braço a torcer q os novos estavam certos, por medo de perder o emprego.

E sobre a regulamentação, acredito que deva ser discutido em outro topico…

Bom, esse tipo de situação é bastante complicada.

Aqui eu vejo duas direções, ou você sai do jogo ou vai pra briga !! Faça um relatório mais próximo possível de um papper, com citações bibliográficas que mostrem o quanto as ações da equipe atual podem impactar e prejudicar o projeto em diversas questões.

Direcione ao fim esse relatório pra quem toma a decisão lá em cima, CIO até se for o caso e deixe o pessoal de cima resolver o que querem, afinal você fez sua parte ! 8)

Kenobi:

Bom, esse tipo de situação é bastante complicada.

Aqui eu vejo duas direções, ou você sai do jogo ou vai pra briga !! Faça um relatório mais próximo possível de um papper, com citações bibliográficas que mostrem o quanto as ações da equipe atual podem impactar e prejudicar o projeto em diversas questões.

Direcione ao fim esse relatório pra quem toma a decisão lá em cima, CIO até se for o caso e deixe o pessoal de cima resolver o que querem, afinal você fez sua parte ! 8)

Concordo 100%.

Agora, acho que isso é um pouco dificil de acontecer, já que na situação do amigo a equipe nova tinha acabado de ser contratada. será que todos estavam dispostos a comprar essa briga? Acredito em união, mas isso só vem com algum tempo de convivência.

Se a empresa tivesse realmente preocupada com o “como” as coisas seriam feitas, e não apenas com o resultado final, teriam contratado alguém para tocar esse projeto, não digo gerente, coordenador nem nada disso, mas pelo menos um arquiteto, senior lider de equipe, algo assim, para poder tomar as melhores decisões tecnicamente falando. Se era pros coboleiros tocarem o projeto, por que não dar um treinamento pra eles? esse negócio de não ter autonomia pra tomar as decisões em projetos é um dos piores modelos pra se trabalhar, pq vc faz errado, sabe que ta errado, sabe que aquilo vai te causar N problemas na hora da manutenção, e mesmo assim é obrigado a fazer. Isso pra mim significa alta rotatividade, e todo mundo perde.

Se o diretor/gerente/seiLaOQue de TI tivesse o mínimo de conhecimento em tecnologia, saberia que seria necessário uma quebra de paradigmas pra trocar esses sistema pra Java, ou qualquer outra linguagem OO. Saberia também que o povo do cobol se sentiria ameaçãdo, e que iria no mínimo dificultar as coisas, para não perder o controle, e consequentemente, o emprego.

Mario, possivelmente o executivo que está bancado o projeto, acredita que está sendo modernizado e não tem o conhecimento tão baixo nível como este para tomar qualquer tipo de decisão, daí a importância de um relatório completo se possível com o Domain que o executivo conhece, como dados de Gartner, ROI e por aí vai … Aí o cara pega a atenção do executivo e provavelmente as coisas mudem radicalmente !! Aliás, se eu fosse o executivo e visse um relatório desse tipo, sinceramente faria uma auditoria e quem o fez iria ser no mínimo promovido 8)

O fato de haver processos estabelecidos não indica que ha bom software sendo produzido. A maior parte das empresas que tem processos estabelecidos seguem um modelo stage-gate (tipo waterfall). O processo está lá, mas apenas atrapanha o desenvolvimento. O problema aqui é que não existe um padrão de fato para um processo de projeto de software como existe para as outras áreas.

Depois, não existem realmente métricas para avaliar ou medir coisa alguma que seja relevante. Leia Clean Code do Robert C. Martin e me diga quais métricas garantem as boas práticas escritas lá. Por exemplo : nomes relevantes. Classes, métodos e variáveis devem ser nomeados com nomes relevantes, ou seja, legiveis, buscaveis, intelegiveis e de acordo com o contexto em que se inserem. Nenhuma ferramenta ou métrica indica esta qualidade. claro que vc pode auditar manualmente o codigo e contar o numero de nomes relevantes sobre o numero total de nomes, mas isso ainda não é uma métrica padrão e não ha ferramenta que automatize isso. Outros exemplos são os comentários relevantes e o controle de exceções. A qualidade do código está em coisas que são obvias quando um desenvolvedor lê o codigo, mas não são obvias às ferramentas , aos IDE ou sequer aos donos de projeto.

Não se trata de ter responsabilidade. Isso sempre está presente. Se um cozinheiro intoxicar alguem ele será punido. A questão é que saber que uma comida está envenedada ou é toxica é simples :vc manda para um laboratorio. Mas não existe um organismo para onde vc manda o codigo para saber se está ok. O problema é falta deste detector de código ruim e não a punição em si. essas já existe na lei para todas as profissões (negligência).

pra essas questões sou anti-herói, pois quando se trata da filosofia de uma empresa, vc não pode mudar nada.
Já passei por uma situação parecida com a sua, tentei expor meu lado e quando me chamaram na gerencia, achei que iam me ouvir, mas queriam me deixar num canto pra não incomodar ninguém. Saí de lá imediatamente, memso ganhando menos fui para um lugar onde as pessoas pensavam como eu, e hj pessoalmente tenho isso como uma grande experiencia de vida.

Como?

FrancoC:

Imaginem que inves de produzir sistemas de informacao gerencias, fosse um software que controla a distribuicao de energia do país. Dai o sistema com alguma falha de vazamento de recursos diante de uma sobrecarga de dados no servidor derruba o sistema. O páis inteiro está na escuridão (qualquer semelhanca com fatos reais é pura coincidencia). Ai as autoridades vao atrás da EDP Bandeirante e descobrem que o sistema era fonercido pela empresa de Joãozinho. Joãozinho ganhou da concorrencia pq jogou o preco para entregar o produto para a metade do que a media que havia sido orçado pelos concorrentes.

Pela milésima vez, isso é fantasia sua. Procure se informar. Em uma licitação fazem-se inúmeras exigências das empresas que se candidatam excluindo assim aquelas fundo de quintal. Exigem coisas como um número mínimo de profissionais com mestrado, todos os profissionais precisam ter no mínimo universidade, a empresa precisa ter no mínimo certificações ISO tal tal tal e CMM nível tal. E também pedem certificações para os profissionais também, tipo certificação dessa tecnologia tal e tal.

E jogar o preço lá embaixo qualquer um pode fazer. O problema é que uma licitação envolve um contrato, e esse estipula condições e garantias para a contratante.

Além do mais inúmeras coisas podem ser a causa de uma falha, visto que PCs não foram feitos para se ter confiabilidade. Se o Windows trava o desenvolvedor é culpado? Se a memória dá problema o desenvolvedor é culpado?

Você já está a várias threads insistindo nesse ponto, e por diversas vezes várias pessoas já explicaram e reexplicaram o por que não funciona. Você tem alguma dúvida?

FrancoC:

Não, não estou dizendo isso.
Também em momento algum eu disse que ao utilizar Hibernate no lugar de JPA voce esta degradando a qualidade do software, ou que uma arquitetura em MVC é melhor do que Pipeline.
Vocês tem um raciocinio muito raso sobre a engenharia de software.
Imagina uma lei proibindo o uso de Struts 1.
Cada coisa que eu leio aqui.

Sim. Você disse:

Você disse que eles teriam que utilizar 100% OO. Você disse que eles teriam que usar as mais recentes práticas (struts 1 é pré-histórico). Você disse que eles teriam que usar padrões de mercado (JPA é o padrão definido pela SUN para persistência Java). Caso contrário, poderiam ser punidos.

Nós temos um raciocício raso (Aliás, não gostei desse termo)???

Cada coisa que EU leio aqui.

Em qual mundo isso? Eu que estou fantasiando mesmo? Ja trabalhei em diversos projetos pro setor publico e nunca vi esse tipo de exigencias, profissionais com mestrado ou no minimo superior. Talvez isso existe na esfera federal, mas em nivel municipal e estadual nunca vi isso.

E eu nem falei em licitação. Falo em terceirizacao no setor privado mesmo.

Thiagosc:

E jogar o preço lá embaixo qualquer um pode fazer. O problema é que uma licitação envolve um contrato, e esse estipula condições e garantias para a contratante.
Além do mais inúmeras coisas podem ser a causa de uma falha, visto que PCs não foram feitos para se ter confiabilidade. Se o Windows trava o desenvolvedor é culpado? Se a memória dá problema o desenvolvedor é culpado?
Você já está a várias threads insistindo nesse ponto, e por diversas vezes várias pessoas já explicaram e reexplicaram o por que não funciona. Você tem alguma dúvida?

Errado. Este é apenas a segunda thread que eu levanto essa questão, e na thread anterior encontrei várias pessoas que tem o mesmo pensamento que o meu. O único motivo de um profissional estar de acordo com a desvalorização de sua classe é falta de conscientizacao.

[favor deletar]

Eu sou totalmente contra uma regulamentação na área de informática, a menos que ela siga as diretrizes da SBC, que regulamenta oficialmente que todos podem praticar a profissão.

Pelos seguintes motivos:

a) Processos em informática mudam muito rápido, e garantem muito pouca coisa. Diferente da engenharia civil, nossos processos ainda são imaturos, e dão poucas garantias. Fora que montar o software, mesmo depois de um processo definido, não é uma tarefa mecânica. O custo para deixar uma solução livre de erros é astronômico, e a burocracia dificilmente acompanharia a agilidade da área;

b) Programadores medíocres vão continuar existindo, mesmo que cursem uma faculdade;

c) Software de risco geralmente está associado a engenharia, que tem regulamentação própria. Por exemplo, todos os softwares já citados nesse tópico (aviões, sistemas médicos, etc);

d) Pisos salariais geram desemprego, ou criam a máfia de assinaturas. Não é possível para um governo tornar um salário artificialmente alto.

e) A área é super ampla, acho difícil fazer uma avaliação profissional genérica.

Agora, sou a favor de mecanismos de certificação mais eficientes. Não seria bacana um “Poscomp” com foco em mercado? Uma prova bem feita certamente tem mais valor percebido que uma lei e valoriza o profissional de qualidade. Como é o caso de algumas certificações de renome, como a da Cisco.

Qualquer projeto no setor público precisa de um processo de licitação onde exigências são feitas. Isso busca evitar por exemplo que políticos contratem amigos ou a empresa da esposa.

Se você conhece alguma empresa pública que contrata empregados sem concurso ou empresas sem licitação saiba que isso é ilegal.

Um projeto grande que seria usado em uma hidrelétrica por exemplo com certeza passaria por um processo de licitação onde as empresas entregariam as suas propostas.

FrancoC:

E eu nem falei em licitação. Falo em terceirizacao no setor privado mesmo.

Empresas com necessidades especiais procuram empresas que possam atender as suas necessidades especiais. Tal “regulamentação” serviria apenas para destruir as pequenas empresas enquanto consultorias e empresas grandes ficariam impunes.

FrancoC:

Errado. Este é apenas a segunda thread que eu levanto essa questão, e na thread anterior encontrei várias pessoas que tem o mesmo pensamento que o meu. O único motivo de um profissional estar de acordo com a desvalorização de sua classe é falta de conscientizacao.

Várias quem? Deve ter tido um ou dois, no máximo. Desvalorização da classe são os baixos salários e condições de contratação que obrigam os profissionais a fraudarem a CLT. Nenhum desses casos seria resolvido por regulamentação. A própria regulamentação visa “defender a sociedade” e não o profissional, ou seja, tudo continuaria igual com a diferença que estaríamos pagando taxas.

Agora você nunca explicou em detalhes como os processos e softwares seriam analizados para verificar a sua integridade. Isso é impossível porque ao contrário da engenharia civil, informática muda a todo momento, novas tecnologias e processos são introduzidos o tempo todo. A menos que você deseje congelar a área de TI no tempo, é impossível estabeler padrões.

ViniGodoy:

Agora, sou a favor de mecanismos de certificação mais eficientes. Não seria bacana um “Poscomp” com foco em mercado? Uma prova bem feita certamente tem mais valor percebido que uma lei e valoriza o profissional de qualidade. Como é o caso de algumas certificações de renome, como a da Cisco.

Em tese concordo com essa ideia,mas quem faria esse teste e como vc certifica que alguem sabe programar ? aliás o que é “saber programar” ? Acho que o problema é mais embaixo.

1. Não ha um corpo claro do que significa “programar bem”. Para mim , programar bem é programar limpo. Para outras pessoas é programar com testes, para outras é simplesmente que o software funcione. Embora hoje se assista a um foco em métodos agíeis como pair programing isso não garante que seja feita boa programação. apenas garante que todos programam igual.

2. Não existe um processo de coordenação de projeto de desenvolvimento de software, mas vários. Isso mostra a imaturidade acadèmica e prática nessa area da administração, mas não na área da informática. se projetos de sotware são mal gerenciados, é problema do gerente que é um elemento administrativo - ao contrario do arquiteto civil que sabe do que se trata a prática do problema. Enquanto isto não foi bem claro e explicito não haverá avanço.

3. Por outro lado um processo brilhante não garante bom código nem boa programação.

O exemplo mais próximo que tenho é o das certificações ISO. A ISO 9001 que as empresas adoram apenas certifica o processoe não o produto. A ISO 20000 que faz isso. Mas veja-se quantas empresas têm iso 20000 e quantas têm e publicitam a iso 9000
Em software é a mesma coisa, a empresa procura um CMMI nivel 5 (que seria equivalente à iso 9001) mas não em ter um bom produto de software.

Tendo a empresa iso 20000 ou não existe o procom para me queixar do produto e da empresa. Mas um cara que compra um softwware queixa-se a quem ? Aliás nos EUA todos vêm como uma licença que exime o produtor de qualquer problema que software cause…

ViniGodoy:

Eu sou totalmente contra uma regulamentação na área de informática, a menos que ela siga as diretrizes da SBC, que regulamenta oficialmente que todos podem praticar a profissão.

Nem UML as pessoas sabem lidar ainda

<blockquote>

b) Programadores medíocres vão continuar existindo, mesmo que cursem uma faculdade;

c) Software de risco geralmente está associado a engenharia, que tem regulamentação própria. Por exemplo, todos os softwares já citados nesse tópico (aviões, sistemas médicos, etc);

d) Pisos salariais geram desemprego, ou criam a máfia de assinaturas. Não é possível para um governo tornar um salário artificialmente alto.

e) A área é super ampla, acho difícil fazer uma avaliação profissional genérica. </blockquote>

Enquanto a Economia do Brasil estiver em níveis como os da Africa não se pode  esperar muito.

Agora, sou a favor de mecanismos de certificação mais eficientes. Não seria bacana um “Poscomp” com foco em mercado? Uma prova bem feita certamente tem mais valor percebido que uma lei e valoriza o profissional de qualidade. Como é o caso de algumas certificações de renome, como a da Cisco.

sergiotaborda:

Esse tipo de prática e postura é inaceitável.

Pessoas com ideias como essas deveriam ser expostas como fraude profissional. É o mesmo nivel de um médico violentar uma paciente ou um cozinheiro mijar na soupa. Eu coloco à votação do todos se acham ético que o nome dessas pessoas e empresa que as mantém no cargo seja divulgado.

Não podemos continuar aceitando esse tipo de coisa. Isso não é apenas um detrimento à nossa profissão , mas a todos os profissionais e à inteligência e cultura humana como um todo.

Concordo plenamente com isso.

Depois de fracassado o projeto, a culpa ainda vai ser dos caras novos e se duvidar o dinossauros vão fazer parecer que a linguagem nova “não serve” ou não atende as necessidades da empresa.

Isso polui o mercado, estimula más práticas, deprime os profissionais e acarreta mais um sem fim de estragos.

Não sei até quando as pessoas vão continuar acreditando em histórias bonitas contadas por RHs, no momento de uma contratação. Todo mundo aqui já viveu milhões de histórias absurdas no trabalho, eu vivi um monte e já contei várias aqui.

Não li todas as mensagens até aqui, mas concordo com os que falaram para você sair desse lugar. Obviamente, quem deve decidir isso é você. Como você mesmo falou, existem pontos positivos em estar nesse lugar, então, enquanto isso for vantajoso para você, segure a onda e vá em frente. Na hora que não for mais vantajoso, saia do lugar. Coloque tudo numa balança e decida.

A pior coisa que existe é ver alguém aceitando se submeter a uma situação incômoda, seja ela causada por repressão/intimidação, por atraso tecnológico, por forma de pensar da empresa etc, chorar rios por causa disso, mas não tomar uma atitude para mudar. Se aceitar, não chore. Se não aceitar, mude.

Entendo que esse assunto leva a temas muito profundos e está enraizado na nossa cultura. Somos submissos por padrão. Esse nosso péssimo costume tem origem na nossa história, por isso talvez é que se veja tantos casos desse tipo por aí, tantas histórias tristes relacionadas a trabalho.

Nesse ponto, eu tendo a ter a mesma opinião do Sérgio Taborda, mesmo que em alguns momentos pareça ser bem radical. Não acho que isso seja errado. Na verdade, eu costumo dizer que problemas absurdos se resolvem com soluções absurdas.

Não vou me estender muito, mas, acho que o que eu posso dizer para ajudar é:

• Não aceitem situações de submissão, em hipótese alguma, em contexto nenhum. O único que sai perdendo com isso é quem aceita.

• Tentem entender o limite da responsabilidade do(s) chefe(s) e a partir de onde começa a sua. Isso é realmente muito sutil e muito difícil de perceber, mas é um prato cheio para gestores mau intencionados (ou muitas vezes sem noção) repassarem suas responsabilidades para as camadas de baixo, afinal, é mais fácil culpar quem está embaixo na hierarquia.

• Tomem suas precauções para poderem ditar o ritmo e os rumos das suas próprias vidas, para não precisarem correr risco de se verem obrigados a aceitar situações de submissão. Isso inclui, por exemplo, reserva financeira. Façam reserva financeira, imediatamente!

E não se esqueçam: um dia nós seremos os dinossauros. Um dia vamos estar com 20, 30 anos de TI nas costas e um bando de moleques cheios de idéias revolucionárias vai aparecer para mudar a forma como fazemos as coisas. Coloquem-se no lugar dos dinossauros de hoje, somente por um momento.

Não, não estou querendo defender esses dinossauros. Realmente existem muitas pessoas que ficaram presas à práticas ruins do passado, mas isso tudo é inevitável. Isso faz parte da evolução da área e tinha que acontecer assim. Talvez nós mesmos não iremos passar por isso, por já estarmos numa fase da evolução da computação que favorece a busca por boas práticas, mas nem todo mundo é assim. Não sabemos o que vai acontecer no futuro. Então, não acho legal criticarmos o que não conhecemos. Como o Kenobi falou, saia do jogo ou parta para a briga, mas tentando evangelizar ao invés de tentar empurrar goela abaixo.

Faltou a parte do quem dá o melhor faz-me-rir… :lol:

Acho que estas dicas são realmente fundamentais. E isto não vale apenas para desenvolvedores, vale para qualquer profissão.
Existe defender a profissão e existe ser submisso. Existe ter orgulho no seu trabalho, respeito pelas pessoas que fazem o mesmo trabalho e parasita que só quer chupar o dinheiro das empresas enquanto pode e aceitar fazer qq coisa por isso. Inclusive trair a confiança dos colegas.

Ter orgulho na profissão, saber impor limites à chefia, e ter uma situação financeira que permita que mande os chefes … para aquele lugar… é fundamental para ser um profissional em qualquer área.

Eu aprendi a programar formalmente em fortran ensinado por geofisicos que aprenderam fazendo. Mesmo nesse tempo e nessa linguagem existiam boas práticas e elas eram ensinadas por quem sabia fazer. Procurar e seguir boas práticas está no sangue de qualquer um que queira fazer as coisas direito mesmo não sendo um profissional de software.

A decadência da qualidade não se deve apenas aos dinosauros mentecaptos, mas também aos novos que querem evoluir na vida sem trabalhar. A nova geração tem a capacidade de se recusar a seguir as más práticas sejam elas velhas ou novas. Ela tem a capacidade de aprender o jeito correto. Mas para isso ela tem que se esforçar. E é esse o problema. A nova geração é demasiado preguiçosa e consumista para entender que excelência se alcança com trabalho. E a sociedades é demasiado anafalbeta para realizar que é a excelência e não a corrupção que cria grandes Homens. enquanto a sociedade e em particular a sociedade de desenvolvedores nacional e internacional continuar aturando a incompetência tecnica e mental de pessoas que poluem as empresas de software nada vai mudar. Numa fábrica normal uma má gerencia leva à greve. Mais uma prova que não existem fábricas de software…

Enfim, atendam à mensagem e não ao mensageiro. Dinosauro ou não, se a pessoa está do lado das boas práticas e principios sigam o que ela diz. Caso contrário ostracisem-na e esqueçam-a. Mesmo que ela mostre um maço de notas na vossa frente. Isso não ajuda, é a cenoura para apanhar pessoas burras.

Acontece q não é tão fácil, a vida é cheia de puxa sacos e hipocrisia, o chefe pode ser um fdp mas quando aparece todos ficam cheios de sorrisos e trovas…

Rola muita grana em Bytes-Codes e projetos Open Source que ninguém sabe quando e como se introduzem no mercado, a verdade é simples quem tem informação não vai passar mesmo, isso garante que os dinossauros se mantém em projetos precários e nada evolutivo, não querem ver os outros se desenvolverem ou assumir cargos.

Se Scrum for introduzido com seriedade e todos participassem de forma à colaborarem isso poderia mudar as questões de projetos e cultura , caso o contrário vai ser essa merda que ai esta.

Not me…

Mas com certeza, não é fácil. Ninguém disse que seria fácil, até porque, como mencionei antes, nós temos uma questão histórica e cultural muito forte impregnada no nosso sangue. Desde pequenos somos acostumados a não questionar os superiores, a respeitar religiosamente quem está em cima, e vencer essa barreira é algo muito complicado. Temos que lutar desde sempre contra isso, sendo que algumas pessoas (a maioria, infelizmente) nem chegam a lutar, simplesmente aceitam.

É claro que eu já me vi em situações de submissão. Principalmente quando era mais novo. Na maioria das vezes, não sabia nem o que estava acontecendo. Mas aos poucos, com a ajuda de outras pessoas, fui percebendo, fui entendendo o que estava se passando e aprendi a me defender e a me impor. Consegui enxergar de forma mais clara o limite que mencionei no post anterior.

Eu já vivi inúmeras situações pavorosas, já contei algumas aqui, e acabei tendo “algumas” gotas d’água que me fizeram pisar no freio com toda a força. As duas principais foram quando eu estava começando a desenvolver um problema de saúde e, anos depois, quando me dei conta de que estava arruinando meu casamento. É muito sério isso, muito complicado.

O que eu sempre vi como problema para a adoção do Scrum nas empresas brasileiras é o fator cultural. Muita gente lucra com o caos, muita gente está acomodada e satisfeita com situações de bagunça total e nem pensam em mudar, e obviamente colocar em prática uma dessas metodologias vai jogar muita merda no ventilador. Talvez por isso é que existam tantos clones mal feitos de metodologias ágeis por aí, porque apesar da modinha, que os gestores adoram, ninguém dessa galera quer expor seus defeitos por aí e ter seu cargo ameaçado.

Acho que isso é coisa do lugar onde você nasceu. Nasci questionando tudo, até porque determinadas coisas são obviamente estúpidas.

Thiagosc:

Acho que isso é coisa do lugar onde você nasceu. Nasci questionando tudo, até porque determinadas coisas são obviamente estúpidas.

Pode ser. Mas onde vc nasceu, todo mundo questiona tudo?

Tem muita Máfia no Mercado.

Alex Basto:

MarcioTavares:

O que eu sempre vi como problema para a adoção do Scrum nas empresas brasileiras é o fator cultural. Muita gente lucra com o caos, muita gente está acomodada e satisfeita com situações de bagunça total e nem pensam em mudar, e obviamente colocar em prática uma dessas metodologias vai jogar muita merda no ventilador. Talvez por isso é que existam tantos clones mal feitos de metodologias ágeis por aí, porque apesar da modinha, que os gestores adoram, ninguém dessa galera quer expor seus defeitos por aí e ter seu cargo ameaçado.

Tem muita Máfia no Mercado.

Máfia não sei, mas vendedor de promessa tem aos montes sim. Isso acontece porque é pratica comum na area de TI o cliente comprar promessas, o fornecedor vender imagem e o programador apagar incendio. Cabe a nos profissionais quebrar esse ciclo vicioso. Dizer que tem mafia por ai não é justificativa pra sentar em cima da bunda e ficar de chororo. A primeira medida seria se recusar a trabalhar para a empresa na medida que descobre como funciona o “esquema”.

Eu sinto mesmo é pelos usuários do software comprado nessas condições, com tantos niveis de indireção entre o criador e o usuário final, que é impossível que o projeto seja considerado um sucesso do ponto de vista técnico e usabilidade. Ou seja, só quem sai ganhando nessa historia toda são os intermediarios que ainda dão grandes bonus de final de ano para os gerentes e puxa-sacos. Logo que constatei isso tratei de remover os intermediarios da jogada. Voce pode fazer o mesmo.

Quando vejo essas coisas, que acontecem em empresas de pequeno/médio porte, e ainda sim estas ganham dinheiro, eu vejo, que nós da área de TI podemos mto bem, programar nas nossas garagens e ficarmos ricos, pq empresas que fazem isso, mais cedo ou mais tarde, fecham as portas, conheço exemplos.

Isso ai galera, vamos ficar ricos!
\o/

Desculpem ressucitar o tópico mais preciso fazer um comentario rapido:

A politicagem domina o mundo bem antes de qualquer um de nós termos conhecimento disto, foi assim, é assim e será assim, quer mudar o mundo seja politico.