As absurdas leis do mundo do software

Algunha vez te preguntaches por que a xente intelixente como os desenvolvedores de software fíxoa con tanta frecuencia? Hai xente que o fixo. Neste post repasamos algunhas das leis non escritas que describen o comportamento dos profesionais de informática.

O meu primeiro ordenador foi un Commodore 64. Case 30 kb de memoria RAM correspondían ao sistema, deixando 32 kb para o procesamento de textos, xogos, contabilidade de empresas familiares e case todo o que fago co ordenador de 6 gb que teño. Iso deixa aberta a pregunta Os equipos actuais responden ás necesidades de software ou o software utiliza máis recursos de hardware porque están dispoñibles?

Por ser xusto, os xogos non son os mesmos, os gráficos non teñen a mesma calidade e sería imposible ver películas e escoitar música. Non obstante, non se pode deixar de pensar iso hai programas que lanzan versións e consumen cada vez máis recursos sen realmente aportar nada novo.

Aquí están as causas.

Lei de Zawinsky

O desenvolvedor de Netscape, Jamie Zawinsky, argumentou iso Cada programa incorpora funcións ata que é capaz de ler correos electrónicos. Se non o consegue, substitúeo por outra persoa capaz de facelo.

Cando o dixo, a broma era que se refería a programas que non estaban pensados ​​inicialmente como clientes de correo electrónico. Deixou de ser divertido cando se descubriu que moitas aplicacións en Google Play pedían permiso para acceder aos compoñentes do teléfono e aos datos do usuario que non necesitaban para facer o seu traballo.

Algúns interpretaron isto como parte dos intentos de espiar aos usuarios. Pero é probable que a natureza humana faga algo simplemente porque se pode facer.

Principio de Peter aplicado ao software

Lawrence Peter fíxose famoso por afirmar que nunha xerarquía, unha persoa ascende a un posto para o que é gravemente incompetente. Pero tamén tivo tempo de dicir algo sobre proxectos complexos:

"Un proxecto complexo farase demasiado complexo para ser entendido incluso polos seus propios desenvolvedores."

Principio de menor asombro

Publicado no IBM Systems Journal en 1984, este principio establece que:

"Se unha función requirida causa unha gran sorpresa, é posible que teña que ser redeseñado."

Noutras palabras, se parte ou todo o software é moi diferente ao que estaba acostumado o usuario, o mellor é un redeseño. O ideal é esforzarse por conseguilo melloras incrementais que son o suficientemente grandes como para ser impresionantes, pero o suficientemente pequenas como para estar familiarizado para o usuario.

Mágoa que Shuttleworth non o tivese en conta cando lanzou Unity.

Lei de entomoloxía cibernética

O primeiro erro na historia da computadora foi real. Unha avelaíña voou nun dos relés dun ordenador MARK II causando un mal funcionamento.

Continuando coa metáfora, a lei da entomoloxía cibernética sostén que sempre haberá un erro máis.

Iso é algo que todos os usuarios de ordenadores saben. Por moito que se probe un sistema operativo, sempre hai un fallo que se descubre cando é demasiado tarde.

Lei de Kernighan

Linux Addicts ten instalado un complemento para garantir que os autores escribamos dun xeito amigable cos motores de busca. Odieino desde o primeiro día. Calquera intento de escribir cun pouco de fuxida literaria denúnciase inmediatamente cun círculo vermello. Co paso do tempo acostumeime e son poucas as veces que teño que facer retoques.

O mesmo ocorre cos programadores, moitas veces están máis interesados ​​en demostrar a súa capacidade de código que en escribir un código máis sinxelo que sexa máis fácil de entender e manter.

Por iso, a lei de Kernighan sostén que:

A depuración é dúas veces máis difícil que escribir o código. Entón, se escribes o código o máis intelixentemente posible, por definición non es o suficientemente intelixente como para depuralo. '

A regra 90/90

Calquera que iniciou un proxecto con ánimo de lucro na vida real sabe que cada proxecto vai levar o dobre de tempo e custar o dobre do orzado, para obter a metade do beneficio esperado.

O mundo da informática ten as súas variantes desta lei. Por exemplo, un Tom Cargill dixo:

"O primeiro 90 por cento do código representa o primeiro 90 por cento do tempo de desenvolvemento. O 10 por cento restante do código representa o outro 90 por cento do tempo de desenvolvemento.

Non estaba claro? Quizais a lei de Hofstadter axude:

"Sempre leva máis do que esperas, incluso tendo en conta a lei de Hofstadter".

Supoño que os desenvolvedores de Ubuntu e Fedora deben sabelo. Ou polo menos lémbrano cada 6 meses.

Lei de Brook

Os proxectos de software de código aberto adoitan ter dous problemas; financiamento e falta de colaboradores. A non ser que o segundo non sexa un problema. Segundo Brook:

"Engadir man de obra a un proxecto de software que está atrasado atrasarao aínda máis".

Por suposto, non só ten que actualizar os novos codificadores. Haberá que documentar máis, necesitará máis burocracia para manter a todos sincronizados e probablemente haberá pelexas.

E, por suposto, non podemos esquecer o amigo Parkinson e a súa afirmación Non importa o espazo baleiro que comece. Sempre necesitarás máis. Referíase ao espazo de oficina, pero o mesmo ocorre coa memoria RAM e o espazo no disco.