Como lidar com mentalidades ad-hoc?


13

Entrei para uma equipe de desenvolvedores de seis há dois meses. As pessoas são legais, tudo é bom. Mas cada vez mais observo uma mentalidade ad-hoc. As coisas são consertadas rapidamente, às custas da usabilidade futura, há poucos testes e duas pessoas admitem, alegremente, que elas gostam de carregar o conhecimento em suas cabeças, em vez de anotá-las.

Como lidar com isso? Eu gostaria de dar o exemplo, mas o tempo é limitado - eu gosto de arquitetar e realmente implementar as coisas. Mas receio que a mentalidade ad-hoc me infecte e, em vez de me esforçar por clareza e simplicidade no design e no código - o que não é fácil de estabelecer -, sou puxado pelo ralo de uma espiral interminável de hacks em hacks - o que não alguém de fora pode desacoplar - apenas por agendamento e administração.


1
Sugiro um chute direto para causar falta de capacidade de reter memórias. A documentação é essencial para qualquer sistema de vida longa ... mesmo que não seja formal.
Rig

14
Bem-vindo ao desenvolvimento de software!
yannis

@YannisRizos, não não não! ;)
Rotian 06/06/12

4
@Rotian Isso é quase leitura obrigatória: joelonsoftware.com/articles/fog0000000332.html . Um pouco desatualizado, mas ainda um grande recurso, e provavelmente vale por si só como resposta.
K.Steff

Em termos mais gerais, eu recomendo / Clean Code / e / The Clean Coder / de "tio Bob". Não concordo com tudo o que ele diz nesses livros, mas eles são muito bons para pensar. Eles certamente abriram meus olhos um pouco!
Michael Scott Shappe

Respostas:


10

Você já conhece parte da resposta: precisa liderar pelo exemplo. Você também precisa se sentir confortável com o fato de que sua "liderança" pode ser ignorada, que seus colegas continuarão a fazer as coisas da maneira que sempre fizeram - seja porque isso deixa o chefe feliz ou porque eles próprios valorizam a conveniência. manutenção de longo prazo.

No final, você precisa deixar seus resultados falarem por si mesmos. Você perdeu um prazo de três dias, mas salvou a equipe de controle de qualidade em pelo menos esses dias programados de teste porque você conduziu seu desenvolvimento de teste e ele funciona em grande parte como projetado? Isso é uma vitória.

No final, no entanto, se você não tem pelo menos algum grau de comprometimento da gerência para esse tipo de troca, você está simplesmente no ambiente errado e precisa encontrar mais um propício para as boas práticas. As más práticas são formadoras de hábito; portanto, quanto mais cedo você encontrar uma maneira de defender sua posição ou mudar para um ambiente de trabalho com melhores práticas, melhor.


Agradeço sua resposta. Acho que você conhece meu ambiente muito bem - tentarei trabalhar mais - e, se eu não conseguir, vou procurar outra coisa.
Rotian 6/06/12

2
+1. Seja a mudança que você deseja ver em sua equipe. Defina o padrão.
Scott C Wilson

2
+1 por permitir que os resultados falem por si mesmos. Que combinado com liderar pelo exemplo é a melhor maneira de afetar mudanças positivas. As pessoas naturalmente querem fazer um bom trabalho (a maioria, de qualquer maneira) e, se virem alguém obtendo resultados melhores do que os deles, provavelmente pedirão o segredo. E é muito provável que ouçam quando perguntam por sua própria vontade do que se lhes for dito, não solicitado.
Erik Dietrich

@Rotian Não é o seu ambiente específico, é claro, mas sim, eu já estive lá e fiz isso. A pior parte foi que, na época, eu nem entendia completamente o quão ruim era. Eu só sabia que algo estava sutilmente errado em um nível profundo, e finalmente decidi que era o suficiente para sair. É apenas nos últimos anos que pude apontar práticas específicas que eles deveriam (ou não deveriam) estar praticando.
Michael Scott Shappe

1

Nada?

Quero dizer, existem restrições de tempo de negócios. Seu cenário pode ser um momento em que o tempo de colocação no mercado é mais valioso do que a facilidade de uso futuro.

Se você é um programador de classificação e arquivo, definir padrões e se preocupar com a arquitetura do produto não é realmente o seu trabalho (especialmente 2 meses). Você deve se esforçar para melhorar o produto da maneira que puder (incluindo mudança de cultura), mas não à custa de alienar sua equipe e / ou chefe. Ser o novo cara que acha que conhece melhor é uma maneira rápida e fácil de fazer isso.

Gostaria de perguntar por que você está fazendo todas essas correções rápidas de hackers? É devido a correções rápidas anteriores de hackers? É fácil, então, ressaltar que, se as coisas fossem feitas "corretamente" em primeiro lugar ...

No final, más práticas de programação levam a dores concretas. Se as pessoas pensam que não, tudo que você precisa fazer é esperar.


1
Pelo que entendi, o problema não é que essas pessoas fazem correções ad-hoc devido a restrições de tempo. O problema é que eles não a veem como uma dívida técnica que deve ser paga em algum momento no futuro. É como pular: você pode sobreviver sem o apoio da Terra por algum tempo, mas é melhor estar preparado para pousar.
9000

@ 9000: o OP diz que é por questão de cronograma e administração, então acho que (principalmente) é pressão do tempo. Subestimar o trabalho real envolvido no desenvolvimento de software não é exatamente incomum.
Telastyn 6/06/12

1
Concordo que más práticas levam a dores concretas; mas a dor concreta nem sempre leva às mudanças que você esperaria ver em um mundo racional. Por experiência, posso dizer-lhe que existem gerentes que não aprenderão com essa dor e não virão incentivar as práticas corretas. Eles continuarão confusos, porque fazer o contrário exigiria que seus chefes advogassem por gastar tempo para fazê-lo "corretamente", o que nem sempre estão preparados para fazer.
Michael Scott Shappe

@UncleMikey: Claro. Mas se seus gerentes são muito ineficazes para agendar as coisas adequadamente, há muito pouco que você pode fazer.
Telastyn

@ 9000 e Telastyn - sim, acho que são os dois - uma certa ignorância sobre o fato de existir algo como dívida técnica combinada com um ambiente que incentiva soluções alternativas por várias razões diferentes (seja hora, hábito, etc.).
Rotian 6/06/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.